Spaghetti Code makes future extension and upgradation of the system an impossible task as it cannot be reused, writes Dr R Srinivasan

" If an organisation follows a good software quality process, it can definitely avoid the occurrence of Spaghetti Code Antipattern"

Another important and noteworthy antipattern that can be identified in software development is 'Spaghetti Code'. Due to hurry or some other pressure, some developers and teams in organisations do not follow any standard software structure of the project work. This leads to lack of clarity, to the extent that even the developer himself will not be able to follow it later if any problem arises during the software development cycle. Particularly if such a situation happens in the environment of object oriented (OO) programming and coding, the interaction between the objects will be minimal, defeating the very purpose of deploying OO technique as far as reuse is concerned. Unfortunately, the development may exhibit that the methods under OO are process oriented and the objects are designated as processes, thereby the execution is controlled by object implementation and not by the clients of the objects.

Other symptoms of this anti-pattern are that the inheritance and polymorphism aspects of OO methods are not used. As mentioned by authors of various anti-pattern books, "Software quickly reaches a point of diminishing returns". Maintenance of such a system will be extremely difficult and uneconomical because mining Spaghetti code is not only mind-boggling but also expensive. Moreover, because of the inability to reuse the Spaghetti Code, extension and future upgrades of the system is almost impossible.

The main cause for an organisation to get into such a situation is due to either employing people without having a strong base on OO design or inadequate training provided to the developers. Then what is the refactored solution? According to William Brown, 70 percent of software cost is due to extensions and so the organisation and the project manager should take care that it is critical to maintain a coherent software structure, which will support future extensions and upgrade. "Well-structured code will have a longer life cycle and be better able to support changes in the business and underlying technology." Another advice is that whenever a new feature is added to a developed system, code clean up should be done to maintain the code structure.

Code clean up will also result in the improvement of the performance as follows: the aim is to achieve a satisfactory structure and so the software team should identify the place where that portion of the performance-critical code exists. Once it is done, they should introduce the required compromise in the structure so that the performance is enhanced.

It is always suggested that the best solution for the Spaghetti Code Antipattern is to prevent it from happening. Four important steps to be undertaken for this are well-documented by William Brown, et al in their book on, AntiPatterns-Refactoring Software Architectures and Projects in Crisis. They suggest that the management should insist on a proper object-oriented analysis process to create a domain model, which explains the system requirements and the range of variability that must be addressed. Moreover, in finalising the design model, it must be assured that the decomposed objects are clearly understood by the developers.

If an organisation follows a good software quality process, it can definitely avoid the occurrence of Spaghetti Code Antipattern because the software requirements (SRS) and design are spelt out well in advance in the life cycle. We have seen in an earlier article another anti-pattern, called 'Lava Flow', which depicts a dead code as part of a system that originated as research but ended up in production. Spaghetti code, in a Lava Flow AntiPattern, will lead to a very complicated situation. Two negatives do not make a positive here!

An example of another mini-antipattern is that of 'Walking through a mine field', named after its identification by Boris Beizer in his paper on, 'Foundations of testing computer software', presented in the 14th International conference and Exposition on testing computer software" at Vienna in July 1997. He says that today's software technology is analogous to walking through a high-technology minefield because while going through a software for testing you find large number of bugs. According to him, in most of the cases, the original source code contains two to five bugs per line of code and this will ultimately result in two or more changes per line to remove all defects. Sarcastically it is mentioned that this antipattern can also be named as, 'Nothing works' or 'Do you believe in magic'.

It is well known that even a simple bug may cause catastrophic effects particularly like computer controlled air traffic systems or real time systems in financial transactions.
Refactored solution for this is that software development organisations should not hesitate to make investment in deploying reliable third party software testing group, even though the software might have undergone testing internally.

A typical system will need five times as much test case software as the production software. Such a thorough testing will speak for the quality of the software.

( To be continued)

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