Software developers should identify the patterns and antipatterns and provide detailed documentation suggesting refactored solutions, in the concluding part of his series on 'Patterns and Antipatterns' Dr R Srinivasan

Having discussed different types of patterns and antipatterns during the last one year, we will conclude this series by taking an example of the steps involved in the case of a single project. William Brown, et al, in their book on 'Antipatterns in Project Management', illustrate the case of a single project with three important steps-identify prevalent problems, investigate their causes, the symptoms and consequences, and then identify the antipatterns, so that it will be possible to arrive at refactored solutions.

Each of these steps is challenging. For example, the problem may not be obviously visible or may be deceptive, or what is seen as a problem is not regarded so by the development team. This needs to be solved through a very thorough review leading to a clear clarification. As the authors of the above book say, "A problem is something more persistent that can be isolated as a risk and must be mitigated". Generally speaking, a typical project will cover both the business risk as well as technical risk, and hence we have already mentioned in an earlier article the stake holders in the project are not only the members of the development team but also the management as well as the customer. It is therefore essential that, in the interests of all, as soon as the risk is identified it should be reported such that the investigation can be completed within a reasonable time.

The procedure does not stop here; it is all the more important to come out with a report on the symptoms that were observed to identify the specific problem and its associated consequences. This is absolutely necessary to investigate the possibilities of any future consequences. All these important observations and precautions are vital to make sure that the overall risk is well understood by the team. What we mean by this is that the project team and management will be able to assess the seriousness of the type of risk. If it happens to be a simple one, the solution will be easy through phase exit criteria. On the other hand, if the risk identification has led to review of the design, the consequences will be very serious leading to effort and cost overruns, or even technical failure of the developed product. The summary is that the state of the problem in terms of causes, symptoms and consequences must be clearly understood to identify the necessary actions to refactor the problem.

This is easily said than done because it is a very critical and iterative activity and should not be rushed. It is critical because it needs to be handled without making the developers worry; it is iterative because any slip up will provide a solution to a wrong problem! This is a typical case of adding more problems to an existing one that is being tackled. Brown, et al, discuss examples under business risks and technical risks-unstable requirements is a business risk, causes for this are lack of rigorous analysis process and weak project management.

The associated symptoms are "repeated analysis tasks and unstable analysis artifacts". The consequences are "continued analysis, delays and cost overruns". Technical risks include "incomplete design", the cause for which may be lack of detailed architecture. A typical symptom for this may be "developers inventing architecture and coding dead ends" and the consequences are "delay in design and coding and associated cost overruns".

While we have seen an illustration with respect to a single project, the practical situation is really different because a software development organisation will not have only one project in isolation. They will have many projects and there will always be some inter-relationship among them. The problem is hence much more complicated, needing more steps to identify the antipatterns and the required refactored solution. The necessary steps are-identification of project inter-relationships, identify individual status of each project and then follow the steps discussed for a single project. In order to identify a cross-project antipattern, the steps must not only to bring out the physical dependencies but also the phase of development for each dependent project.

In these articles, we have identified antipatterns and the suggested refactored solution for each, but these are not the only ones. There may be many more because software development is a never-ending activity. With newer technologies coming in, there will be more need for developing associated software and convert that technology into a viable product for consumers. It will be a very good service to the software community, if developers reveal the patterns and antipatterns and provide good documentation on them with suggested refactored solution.

(Concluded)

( To be continued)

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