|
 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, iCMG, Bangalore.
He can be contacted at r.srinivasan@icmg.nu)
|
