Development team should identify the risks

It is necessary for software developers to identify patterns and antipatterns in the development process and provide detailed documentation suggesting refactored solutions, writes DR R SRINIVASAN, in the concluding part of his series on ‘Patterns and Antipatterns’

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 a single project. William Brown, et al, in their book 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 locate 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 absolute 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 business risks as well as technical risks, and hence we have already mentioned in an earlier article the stake holders in a 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. This will make it possible for investigations to be completed on 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 a 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. The project team and management will be able to assess the seriousness of the type of risk. If it happens to be simple, the solution will be easy. 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 easier 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”. 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 solutions. The necessary steps are—investigating project inter-relationships, identifying 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 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)

The author is Chief Technology Officer, iCMG, Bangalore.

He can be contacted at r.srinivasan@icmg.nu