Back in the 1980s a few developers realized that common patterns appear in the code everybody was writing. They documented them in 1995 a famous book called “Design Patterns: Elements of Reusable Object-Oriented Software”. Today, many software teams have a guideline stating they must use design patterns.
In early 1990s, one former US AirForce pilot became Chief Engineer of a software company. The teams he was working with had many troubles while developing a product. Trying to fix the issues, he decided to fundamentally change their workflow. In 1995 he introduced his new method to the world under the name of Scrum. Today, software teams adopting it often focus on one thing: how to do Scrum by the book.
I can only imagine how the world would have evolved if we treated hammers in the same way. Someone needed to bind two pieces of wood together, thought of nails and used a piece of metal to drive them. He shows his method to other people, they all use it and they call it “hammer”. The 3rd annual convention on the topic focuses on making hammers too light to drive nails anymore.
It doesn’t mean that design patterns are bad, Scrum is useless and hammers aren’t helpful. Just that we tend to forget the purpose and focus on the method.
There’s a pattern in these stories:
- someone has a problem
- they find a solution
- more people apply the solution
- applying the solution becomes more important than fixing the problem
Fancy name: “The Purpose-Method Substitution”.
Earthly name: “The Hammer is More Important than Driving Nails”. For short: THIMIDN.
When I coach teams it’s important to find THIMIDNs. I start by questioning the purpose of a certain practice. If:
- I can’t get an answer Or
- The answer focuses on the method and not the purpose
then I nailed it (whoops, pun).
For example:
“Q: Why are you doing the daily Scrum?
A: To answer the three questions”
“Q: How will this feature help your users?
A: We don’t know. The Product Owner told us to add it.”
The greatest risk of a THIMIDN is that teams optimize the method. If the purpose of the Daily Scrum is to answer the three questions, why have a meeting? If the purpose is to use design patterns, why not use AbstractFactories of Strategies aggregated with Adapters for Facades? If the purpose is to develop what the Product Owner says, why understand the users?
I’ve seen agile teams experiencing THIMIDN in a few typical situations:
- Communication blockages
- Shallow understanding of principles and practices
- A company culture that encourages reliance
I use three steps to revert the substitution:
- Clarify the purpose: Why?
- Negate the practice: When not to use it?
- Find alternatives: What else can we do?
For example:
- What’s the purpose of design patterns? To get better design.
- When shouldn’t you introduce design patterns? When the design is very simple.
- What other method can we use to get good designs? Test Driven Development.
So here it is, the brief version of The Hammer is More Important than Driving Nails (THIMIDN):
- You know the method is more important than the purpose when nobody can give you a satisfactory answer to why they’re doing what they’re doing
- Ignore it at your peril, because teams will optimize the method and might not reach the purpose
- Act upon it by clarifying the purpose, negating the practice and finding alternatives.
Just don’t allow the method for finding and removing THIMIDNs become more important than, well, finding and removing THIMIDNs.