Antipatterns do not occur in isolation, and one antipattern usually leads to a chain of many others. Such disasters however can be avoided by adopting suitable processes and refactored solutions during the project development life cycle, writes Dr R Srinivasan

We are all aware of following an appropriate process model that would suit every phase of the software development life cycle. Organisations which have good experience in adopting the software process would agree that a lapse in any phase affects the other phases in the course of software development. Perfectness in each phase of the development process is interrelated with others, therefore an antipattern in one phase will have a secondary effect on one or more phases. In short, antipatterns do not occur in isolation and particularly over a time period there might be possibility of one antipattern leading to a chain of other antipatterns.

Software experts like Brown, McCormick and Thomas say, "It is important to understand the relationship of known antipatterns to the phases and activities throughout a software development cycle, and the major antipattern relationships of causes, symptoms and consequences." They explain a model in which the necessary interrelationships are depicted horizontally across the software development phases and vertically with important aspects of software configuration management (including the processes involved in project management). This model is good as it provides guidance in enumerating the antipatterns in a sequential manner as part of the software development life cycle. A typical sequence comprises Software Development Antipa-ttern, Software Configuration Management Antipattern and Project Management Antipattern.

We have seen in an earlier article that a typical software development project involves a sequence of phases like determining its scope, deciding the software requirement specifications followed by requirement analysis, finalising the software architecture, proceeding to a high-level and then low-level design (coding) of individual modules (units), unit testing, integration of modules into a system and finally system testing. We have already discussed some of the antipatterns that are detected during the software development phase. The typical ones are: Requirements Jeopardy Antipattern that happens due to misunderstood specifications, or the case where document on SRS and analysis are missing; Analysis Paralysis Antipattern which happens due to the decision of arriving at highly sophisticated models which may not be very useful for the processes down the line in the development phase; the Blob Antipattern which is a procedural design separating process from data in contrast to the much needed object-oriented design process; the Lava Flow Antipattern that is responsible for bringing in a set of models and codes that have been developed long ago and have no documentation, resulting in a situation that the present team struggles hard to understand; and Sure Thing Antipattern where the team and the management are overconfident that testing is not necessary.

Coming to interrelationship with vertical activities, let us first take the case of antipatterns in Software Configuration Management (SCM). They are: The Silver Bullet Antipattern where a tool is taken to be more reliable than adopting the necessary process in SCM; CM Takeover Antipattern, in which the person in charge of CM takes control of the project and emphasises SCM as the only focus; Failure to Audit Antipattern happens while omitting audit as part of SCM; problems caused by inexperienced person put in charge of SCM, etc.

Similarly, we have described many antipatterns under project management, during the last few weeks. They are Corncob Antipattern, Nil Desperandum Antipattern, Planning 911 Antipattern, Micro Management Antipattern, etc.

It should be borne in mind that the antipatterns happening in each phase of the life cycle development may lead to antipatterns in other phases, both in horizontal direction as part of the project development, and also umbrella activities like SCM and project management processes vertically. Such a catastrophy can be avoided if proper care is taken to adopt suitable processes and refactored solutions at each stage during the development cycle.

( To be continued)

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