It is important to consider the compatibility of an existing system with a new one and implement the one that is best suited, rather than following an existing approach, says DR. R. SRINIVASAN.

"'Dead End' antipattern happens when reusable components bought from a specific vendor are not maintained or supported by him "

In our day-to-day life, because of the salesmanship quality of a shopkeeper, some of us always go to the same shop without even bothering to find out whether we will be able to get either a better quality product or a discount elsewhere. Such behaviour can be seen even among software developers; while this may be accepted in the former case, this tendency will lead to another common anti-pattern in software development. Because of the expertise and familiarity gained through using a specific tool or product from a vendor, the members of the project team think and try using the same under the assumption that any new solution or development effort can be solved using the same tool all the time.

This is mainly because of the false assurance given by the vendor that future extensions and upgrades of this product will be highly useful and adaptable by the development team. The project team, including the manager, feel comfortable with an existing approach and are not ready to learn and implement that which is better suited for their purpose. This type of anti-pattern is known as the 'Golden Hammer', which is wrongly misconceived as the best tool or solution to most of the needs of a software development organisation.

Brown et al say that advocates of the Golden Hammer will argue and try to justify that future extensions to the technology, which are designed to work with their existing products, will minimise risk and cost. It may even happen that the members of the project team will go to the extent of arguing with systems analysts and the customer suggesting requirements, which will be met with by a particular tool and at the same time screening them away from areas where the tool does not properly fit. From the management point of view also, this view may be supported, thinking that a large investment has been made in training people in a particular product or tool.

What are the consequences of such an anti-pattern? The so-called familiar tool may dictate design in new developments and even make the system architecture rigid for future expansion. Solutions under Golden Hammer will ultimately result in inferior performance and scalability. The consequences of this misconception and misconstrued argument of the team will be realised only after long hours of toiling and sweating as part of the development cycle, thereby leading to schedule delay and escalated cost of development. Experts go to the extent of identifying such a team, which has been responsible for advocating the Golden Hammer, to be the one having lack of knowledge and experience with other better alternative tool/products available in the market.

Quite naturally the organisation will soon realise this grave mistake and find out what are the refactored solutions. It has been suggested that the solution in effect is in two parts, viz., philosophical in the general sense and a change in attitude in the development process. Philosophically, right from the top to the bottom in an organisation, there must always be an awareness of technological development in the areas of their activity, the types of new tools or products which will best suit for the specific requirements, etc.

Secondly, the management must have the commitment to expose and train the developers in the organisation towards this concept so that they are abreast with new developments in technology. In today's parlance of object-based and component-based software development, it should be borne in mind that any such component must insulate the system from proprietary features in implementation.

There is also an imminent danger, if the developers try to stick to the same tool all the time like the Golden Hammer. This attitude may also introduce another consequential anti-pattern called the 'Dead End', which will happen if the reusable components bought from a specific vendor are not maintained or supported by him. Because of the proprietary nature of these components, it will not be possible to modify them to a new environment and so the project may meet the Dead End. This anti-pattern is also known as the "Components off the shelf (COTS) customisation". The consequence of this will be not only lead to escalation in cost but turnover of disgruntled developers who get frustrated in wasting their time in working around the vendor's product inadequacies.

( To be continued)

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