This post originated from an RSS feed registered with Java Buzz
by Jiri Lundak.
Original Post: Beware of ... Fragile Software
Feed Title: Jiri on Java and Jini
Feed URL: http://www.kstaken.com
Feed Description: Jiri Lundak's thoughts on Java, Jini, Distributed Systems and Software Craftsmanship
This is my fist take at the 'Beware of' series...
In the last 8 months our company has been using an application development framework (for implementing a browser-based application), that is licenced from a partnering company.
While the speed with which to develop web applications is quite fast, the underlying architecture makes for fragile applications.
What do I mean by 'fragile'? When we look up the word's meaning in a dictionary, we get (according to the Encarta World English Dictionary):
easily broken: easy to break, damage, or harm, usually because delicate or brittle
easily destroyed: not strong, sound, or secure and unlikely to withstand any severe stresses and strains that may be put on it
>>> How can an application be 'fragile'?
Fragility in the context of software manifests itself in different ways:
From project managers' view:
You are slipping delivery dates
You can not statisfy aggreed upon SLAs (Service Level Aggreements)
Your developers pass more time chasing bugs, than implementing features
From users' view:
The application behaves eratically different under load
The system does not look and behave in a consistent manner
The users get errors and do not know what happened
Each release changes the systems' behaviour
The system does not fit the users' working style
From developers' view:
The application gets difficult to maintain and upgrade over time
Changes brittle through the whole application and all layers
The software tends to break easily, wenn you modify some code and this leads often to a system, that is better not touched, when it runs.
Software developers prefer to implement similar functions anew(by copying and pasting) instead of making reusable components(by refactoring)
Your business logic tends to be dispersed between layers
You do not understand fully the implications of your code modifications
Many semantic breaks in your code (no hawks-eye view of the system)
>>> But what can us lead to fragile systems?
There are many different factors that influence how we implement a system.
The most prominent factors, that make a system fragile are:
No real system design
All features are implemented in a hurry (over-ambitious management)
The used development plattform does not encourage, code reuse and subsystem-building, nor testing
Accumulated code cruft
Use of many different programming techniques (HTML, Scripting, Server-side logic,Client-side logic, Server-side includes, etc.) without guidelines and consistency
No communication between team members
Management declares each developer a Lonesome Cowboy Coder (assigning one or multiple projects to each developer)
Many uncoordinate changes in project assignment, changing priorities every twodays
Deceitful productivity (if your management thinks you have done all the workwhen they see the user interface)
Plus some low-level stuff (by no means a complete list):
Global variables (so there are more parameters than your method signature shows)
Bad exception handling policy
Not having the source code of a framework you use (if it is not very well documented)
>>> What should we do to make our system more robust?
One thing is clear: there is not any one system that is not sometimes in a 'fragile' state. In the end, it all boils down to our attitude to building quality software systems and whether we are in the position to influence the direction a software developement project takes.
If your management is supportive of your attitude to build a system as robust as possible,then you can eventually not allow 'fragility' to creep into your application. You will be giventime and resources to remove 'fragility' factors wherever you encounter them.
But if your company chiefs only see the immediate profit and are dazzled by deceitful productivity,thinking, that with some specific framework you can implement an ERP system in two weeks,then you have a problem. Then your are very likely in the wrong place.
To minimize your systems fragility you can...
reduce the number of used tools and techniques to develop it
never disperse your business logic in different layers (and never put it in the UI)
modularize your system (if it is large), build subsystems
use reusable parts (components) wherever possible
disallow cut and paste coding
build a team and do not let it fall apart (by not communicating and assigning them tocompletely different tasks)
test, test, test
follow the KISS principle (without being naive)
do not rush development (though we are living in a world of rapid change)
This was kind of an overview installment of the 'Beware of' series. Next time I will try to focuson what I mean by 'deceitful productivity'.
I am curious to know what you think about the topic?
Previous Topic
