The Golden Hammer Anti-Pattern

An anti-pattern is a pattern that describes one or multiple ways of how NOT to solve known and repetitive problems in your architecture, code or tools. Anti-patterns are evaluated as bad software design and are usually harmful or, in the best case, ineffective.

Anti-patterns have also the magical ability to add useless and time-consuming tasks, that is often categorised as “technical debt”.

In this article, I will talk about the Golden Hammer anti-pattern, which is very common in software engineering, and occurs even in highly skilled teams.

Anti-Pattern Identity Card

Name: Golden Hammer

Also Know As: Old Yeller, Head-in-the sand

Major Root Causes: Ignorance, Pride, Narrow-Mindedness, Overrated confidence

Most Applicable Scale: Application

Refactored Solution Name: Expand your horizons

Refactored Solution Type: Process

Unbalanced Forces: Management of Technology Transfer

How to Spot:

• “I have a hammer and everything else is a nail.”
• “Our database is our architecture.”
• “Maybe we shouldn’t have used Excel macros for this job after all.”

Examples

This is one of the most common AntiPatterns.

Frequently, a vendor, let’s say a database vendor, will advocate using its growing product suite as a solution to most of the needs of an organization. Given the initial expense of adopting a specific database solution, such a vendor often provides extensions to the technology that are proven to work well with its deployed products at greatly reduced prices.

Most common cases

A software development team has gained a high level of competence in a particular solution or vendor product, referred to here as the Golden Hammer.

As a result, every new product or development effort is viewed as something that is best solved with it. In many cases, the Golden Hammer is a mismatch for the problem, but minimal effort is devoted to exploring alternative solutions.

This AntiPattern results in the misapplication of a favoured tool or concept. Developers and managers are comfortable with an existing approach and as a result, would be not willing to learn and apply one that is better suited.

This is typified by the common “our database is our architecture” mindset, particularly common in the world of banking services.

Frequently, an advocate, who can be a very talented team member, will propose the Golden Hammer and its associated product suite as a solution to most of the needs of an organisation. Given the initial expense of adopting a specific solution, Golden Hammer advocates will argue that future extensions to the technology, which are designed to work with their existing products, will minimise risk and cost.

How to spot it and what are the impacts?

1 — Similar or identical tools and products are used for wide range of conceptually diverse products.

2 — Solutions have inferior performance, scalability, and so on when compared to other solutions in the industry.

3 — System architecture is best described by a particular product, application suite, or vendor tool set.

4 — Developers debate system requirements with system analysts and end users, frequently advocating requirements that are easily accommodated by a particular tool and eliminating or masking them from areas where the adopted tool is insufficient.

5 — Developers become isolated from the industry. They demonstrate a lack of knowledge and experience with alternative approaches and even, in worst cases, show difficulties in “out-of-the box thinking”.

6 — Requirements are not fully met, in an attempt to leverage existing investment. No Golden Hammer is able to cover unconditionally and forever 100% of all requirements.

7 — Existing products dictate design and system architecture, and could even blindly block the integration of better products.

8 — New development relies heavily on a specific vendor product or technology.

9 — Technical skills are not efficiently evaluated.

What could lead you there?

• Group is isolated from industry, other companies.
• Several successes have used a particular approach (Generalisation bias).
• Large investment has been made in training and/or gaining experience in a product or technology.
• Reliance on proprietary product features that are not readily available in other industry products when implemented.
• Corncob proposing the solution (we will discuss the Corncob AntiPattern in another article. Shortly, Corncob is a slang term frequently used at Object Management Group, a software consortium, to describe difficult people in a team or an organisation).

Could it work or be appropriate, in some cases?

Good question! Indeed, the Golden Hammer AntiPattern sometimes works, but under one these of specific conditions:

1 — If the product that defines the architectural constraints is the intended strategic solution for the long term. For example, using an Oracle database for persistent storage and wrapped stored procedures for secure access to data.

2 — If the product is part of a vendor suite that provides for most of the software needs and the totality of business use cases.

How to avoid this AntiPattern?

The solutions to avoid or to fix it is not always obvious. They involve a philosophical aspect as well as a structural one and also a change in the development process. Philosophically, a team, a company or an organisation need to have commitment to a continuous exploration of new technologies.

Without such a commitment, the danger of over-reliance on a specific technology or vendor tool set will always exists, and would be harder to fix over time.

This solution requires a two inter-dependant approaches:

1 — A greater commitment by management in the professional development of their developers.

2 — A development strategy that requires explicit software boundaries to enable technology migration.

The software design role

Software systems need to be designed and developed with well-defined boundaries that facilitate the replaceability of individual software components. With a solution architecture, design schemas, with feature oriented approach, a component should insulate the system from proprietary features in its implementation.

OMG IDL

If a solution is developed using explicit software boundaries, the interfaces that make up these limits become points at which the software used in the implementation may be replaced with a new implementation, without affecting the other components in the system. An industry standard, such as the OMG IDL specification, is an invaluable tool for incorporating rigid software boundaries between components.

The Developers role

Furthermore, software developers need to be up-to-date on technology trends, both within the organisation’s domain and in the software industry at large. This can be accomplished through several activities that encourage the interchange of technical ideas. For example, developers can establish groups to discuss technical developments (design patterns, emerging standards, new products) that may impact the organisation in the future, or in wider vision, small workshops for testing new technologies or tools that would continuously challenge the existing boundaries.

Developers (or I’d rather use team members) could also form book study clubs to track and discuss new publications that describe innovative approaches to software development. In practice, I have found the book study club paradigm to be a very effective way to exchange ideas and new approaches.

Even without full management implication, developers can establish informal networks of technology-minded people to investigate and track new technologies and solutions. Industry conferences are also a great way to contact people and vendors and stay informed as to where the industries are headed and what new solutions are available to developers.

The Management role

On the management side, another useful solution is to adopt a commitment to open systems and architectures without excluding the possibility of using proprietary systems if needed. Without this kind of commitments, developers would often acquire the attitude that, achieving short-term results by any means necessary is acceptable. Though this may be acceptable or even desirable in the short term, future results will certainly become problematic because rather than building upon a solid foundation of past successes, effort is expended reworking past software to conform to new challenges.

The Code role

Flexible, reusable code requires an investment in its initial development and design, otherwise long-term benefits will not be achieved.

Also, the danger of over-reliance on a specific technology or vendor tool set is a potential risk in the product or project development. In-house research programs that develop POCs (or proof-of-concept prototypes) are effective for testing the feasibility of incorporating less risky open technologies into a development effort.

The Hiring role

Another management-level step of eliminating or avoiding the Golden Hammer AntiPattern is to encourage the hiring of people from different areas and from different backgrounds. Teams benefit from having a broader experience base to draw upon in developing solutions. Hiring a database team whose members all have experience in using the same database product or even worst, who have worked on the same projects previously, would greatly limits the likely solution space, in comparison to a similar team whose experience encompasses a wide range of database technology solutions.

The Professional Development

Finally, management must actively invest in the professional development of software developers, as well as reward developers who take initiative in improving their own work, and as consequence, the team’s work.

Could a single team member be the cause?

Unfortunately, it is a common variation of Golden Hammer, that occurs when a developer uses a favorite software concept obsessively. For example, some developers learn one or two of the GoF patterns (Gang of Four Design Patterns) and apply them, blindly, to all phases of software analysis, design, and implementation.

Even team discussions about intent or purpose could sometimes be insufficient to sway them from recognising the applicability of the design pattern’s structure and force-fitting its use throughout the entire development process.

As a simple step to avoid this variation of the Golden Hammer, education and mentoring are required to help people become aware of other available approaches to software system construction.

The Golden Hammer is no secret for you now. We have seen how to identify it, what can we do to avoid it and what is the role of every component of the organisation to set continuous solution against the instauration of this AntiPattern.