'Lava flow' antipatterns leave behind dead codes, which in the absence of proper documentation, will not only be very difficult to analyze, test and modify but also lead to an unstable system, writes DR. R. SRINIVASAN

" Lava flow is detected in systems that have evolved out of extensive research and ultimately result into production"

IT was mentioned in the last article that antipatterns would offer a refactored solution for successful software development. However, the question of refactoring comes into the picture only when an organization discovers antipatterns during the process. Unfortunately, the topic itself being new, many software developers may think that absence of antipatterns guarantee that their development is successful. So the crux of the matter is that people have to be educated on this aspect that antipatterns are the most appropriate for resolving chronic problems.

Antipatterns occur at different stages of the software development life cycle. After describing Blob last week we will take up what is called 'lava Flow'. This AntiPattern is detected in systems that have evolved out of extensive research and ultimately resulting into production. Because of the long duration of the research segment, some of the developers would have left the organization without documenting the purpose and function of some specific code segments. This will leave the future players, in development, looking aghast at a mass of immovable code and not knowing what to do with it. To quote in the words of William Brown, "The result is several fragments of code, wayward variable classes, and procedures that are not clearly related to the overall system. In fact, these flows are so complicated in appearance and spaghetti like that they seem important, but no one can really explain what they do or why they exist." Because of this characteristic of unknown mass of flow of code, the AntiPattern derives the name as 'Lava Flow'.

At the critical time of production, neither the developers nor the organization will find time to study this portion of the code and will be very happy to take the system to the market as long as it works; but what are the consequences? Such a system will be of very poor design because in a hurry the developers throw the sound design practices and quality aspects into the winds, in order to beat the time to market in competition with other vendors. From the angle of software quality control, in such systems verification and tests are rarely possible. Because of the unnecessary size of the Lava code, the system will become expensive and occupy extra resources leading to poor performance. Also, the very basic concept of reuse in object oriented design will not be possible. Brown et al, in their book on 'AntiPatterns, Refactoring Software Architectures, and Projects in Crisis', identify the typical causes for this type of AntiPattern as follows:

1)	Development during research phase of the system does not implement configuration management.
2)	Several trial approach to achieve some specific functionality resulting in uncontrolled distribution of unfinished code.
3)	Many a times that segment of code might have been developed by an individual who has left without explaining what it is and why.
4)	Lack of proper software architecture or change in the middle of the project.
5)	Frequent changes in development and in a hurry to meet the deadline no proper documentation and change control.

To summarize, Lava Flow AntiPattern leaves behind "dead code" which, in the absence of proper documentation, will not only be very difficult to analyze, test and modify, but also lead to an unstable system raising its head at a critical time in the field when being used by the customers. Under this embarrassing situation, if the existing Lava Flow code is not removed, it may continue to proliferate as it is reused in other areas leading to many more complications in terms of stability.

Moreover, in the process of removing it and in a hurry to revoke the system, the maintenance people may introduce secondary flows thereby compounding the problem. Just like the lava flow of a volcano, if the flow hardens, it is impossible to understand its architecture and rectify. So, it has be borne in mind that in order to prevent the lava flow AntiPattern, proper care should be taken to decide on a firm and a suitable architecture before the development work starts and this should be backed up by a strict configuration management and change control. It is also important to establish the components that are necessary for the development of the system and also firm up the necessary interfaces among them.

( To be continued)

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