Software projects are often subjected to severe constraints in schedules and associated stress and any hasty decision often leads to compromises on quality aspects, writes Dr R Srinivasan

IN the last article we defined AntiPatterns as the one which will guide us to avoid and prevent us from repeating certain mistakes committed in a project earlier. Patterns are abstractions of experience; AntiPatterns are more difficult to draft, but rapidly lead to sharing of experiences. In practice it is much more difficult to identify the situations that should be avoided, particularly so in software development and that is the challenge tackled carefully through Antipatterns in many phases of software life cycle development. Through AntiPatterns it is possible to clearly identify bad concepts followed in design, the approaches taken to follow it towards development that would lead to a software of poor quality, ultimately resulting in the failure of the project, Johnny Johnson in his article 'Creating chaos' in the July 1995 issue of American Programmer says that five out of six corporate development projects fall short of desired features because of bad practices.

Let us see one example here - one important parameter attributed to the success of a well-planned software development project is "on time delivery".

In majority cases this does not happen and therefore because of the slippage in schedule, the morale of the team will go low and the project will suffer further. Another example will illustrate as to what will happen when the customer appears in the middle of the project and wants the time schedule to be reduced so that the market earlier than that of his competitors; but he will not realize that this demand will lead the project into what is called as "Swamp Effect". Brown et al describe this effect as the situation where there are finite number of alligators in a swamp and if we compress the size of the swamp into a smaller area (equivalent to schedule compression in software development), we increase the likelihood of being eaten by an alligator!!

AntiPatterns are much more effective and appropriate for identifying and describing recurring solutions than Design Patterns, because they start with a solution that has been adopted wrongly by the project team and refactor towards perfection. As part of the software life cycle, AntiPatterns can be viewed through the viewpoints of the developers, the software architect and the project manager. While AntiPatterns identified during development illustrate the problems encountered by the programmers, problems in system architecture, structure and consequences come under Architectural AntiPatterns. Management AntiPattern illustrate problems and solutions in the overall perspective and the software organization.

The three common concepts that depict AntiPatterns in software project development are:

1) Root causes that pin point the context and situations for detecting AntiPatterns,
2) Primal forces that influence the decision making and
3) The model adopted in software design typically based on the chosen architecture.
A good understanding of architectural levels is needed for defining the different scales of pattern applicability.

Brown, et al in their book, 'AntiPatterns - Refactoring Software And Projects in Crisis', illustrate that root causes are the mistakes committed during the development cycle leading to effort/cost over runs, schedule slippage, etc. According to them, the main reasons attributed are haste, apathy, narrow mindedness, sloth, avarice, ignorance and pride.

To describe each one of these briefly, software projects are often subjected to severe constraints in schedule and associated stress and so under this situation any hasty decision will lead to compromise in quality aspects.

Apathy denotes a situation when the developers or the project manager are unwilling to accept and adopt to solving known problems. Narrow mindedness is another form of apathy where the people refuse to adopt solutions that are known to be effective. Sloth is the attribute of a sluggish or lazy person in the project who makes poor decisions based upon an easy and short cut answer.

When the software development model incorporates excessive but superfluous details, we call it a situation of avarice. This will not only lead to unnecessary complexity of the system but also towards effort and cost overrun.

Ignorance is intellectual sloth that happens when a person does not try to learn or understand resulting in long term software problems. We will discuss about AntiPatterns due to primal forces and the model adopted in software development in the next article.

(To be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)