In my previous post I explained how software anti-patterns are symptoms of bad habits that can be endemic to entire teams. Today I want to talk about what is perhaps the most infamous of all: the Golden Hammer. Actually, it’s a collection of hammers that makes up the toolbox from hell.
The Golden Hammer anti-pattern is a result of narrow focus, which in itself is an admirable and even necessary character trait for many pursuits: there’s a lot to admire in people who become experts in their chosen specialised field. It takes dedication and stamina. Science wouldn’t have made it to its present state without it. However, what makes a hammer golden is having experience and affinity with a technique (framework, language) that in itself has a limited range of applications but that you misapply through overuse. The operative words are rash thinking, tunnel vision and bad fit. You tend to have your solution ready before you understand the problem, like a doctor writing a prescription before the patient has finished telling what ails her. Worse: you always prescribe the same drug. Instead of the metaphor of the hammer and the nail you could also think of the Golden Shoehorn or the Cinderella pattern: you have only a single shoe and need to make every foot fit. That’s gotta hurt.
Mind you that it’s not the technique itself that constitutes a Golden Hammer: it’s people that make it so. Sure, this smacks of the dubious argument “guns don’t kill people; people do”. Like some guns are more lethal than others, some tech is a more likely candidate for hammering. If it’s hard to learn, expensive, and yet has limited usefulness, you can bet the fanboys will stretch it to breaking point.
Golden Hammers are often lumped together, but they’re not created equal and we should make some distinctions for better understanding. Within a language, there’s the pet design patterns, not only rampant in junior developers who just heard about the Gang of Four, but also popular with abstraction fetishists in general. Team consensus about coding which is more mature than discussing tabs versus spaces can hopefully improve this. Management need not be involved: they won’t understand.
We’re getting into even murkier water with a third sub-category: the architectural shoehorn. This is a mindset that pervades entire organisations, and the predominance of the relational database is a good example. You see it in organisations where secure and (ACID) reliable storage are top priorities, like in banks and insurance companies. When the database is the architecture, all applications are tightly coupled to this single linchpin and bottleneck. Within these organisations you will find a species of developer fluent in SQL, who can automagically turn every requirement into an entity-relationship diagram. Even if you get them to admit that their Oracle isn’t always the best fit, they’ll concede it’s the only fit they know, or are allowed.
There must be something irresistible about the Golden Hammer, or we wouldn’t be grabbing it so often. To begin with, it feels familiar. New frameworks with incompatible new versions are hurled at us at a frantic pace. It sucks having to tread water like a newbie all the time. Please man, just give me some time to become good at this so I can feel productive!
Then you have familiarity or status quo bias : there’s an evolutionary advantage to preferring what is familiar over what is new. Better the devil you know than the devil you don’t, or if Chinese philosophy is more your speed: the fastest route between two points is the road you know. Sticking with what you know does have its advantages. It makes for more predictable planning because there are fewer unknowns. No optimistic early adopter bloggers who claim that all it takes to upgrade from Angular 2 to 4 is a single npm statement (like so much on the internet, this is a damn lie). Everyone in the team is comfortable with the toolset or at least knows its quirks — until they get a nervous sense that all this legacy tech looks bad on their cv and they leave.
I was saving the biggest hammer for last because I need to warm you up for the following bold claim: I consider writing code itself to be the biggest Golden Hammer of all. Why is that? It’s because developers like coding so frigging badly. But there’s more to developing software than writing code. We know it, and promptly forget it. It’s like the popular Hollywood monster movie pattern where our heroes anxiously wonder where the monster has gone, at which point the camera zooms out, the orchestra kicks in, and they run for their lives. It’s the Millennium Falcon caught in the belly of the worm.
If you step into a Mercedes dealership they will try to sell you a Mercedes, because that’s what they have. They don’t care whether you have a place to park it. They’re not going to recommend a Toyota, even when they question your disposable monthly income. They’ll assume you can afford it. When a customer comes to a software company they’ll assume that customer wants a software solution to their problem. But it’s the customer who assumed it in the first place, and perhaps it was a mistaken assumption. If we are truly committed to customer satisfaction we should tell them “sure, we can build it, but you’d be wasting your money”.
Every course on software architecture and requirements engineering will teach you that you need to decide early on whether to build or buy the solution, either entirely or in part. You need senior techies to help you decide, but it would be wiser if these are not the ones who doing the actual coding. “Can we get this meeting over with, my fingers are itching and I don’t care if it’s been done already”. The not-invented-here syndrome is a pure example of coding for coding’s sake.
Here are the alternatives to writing it yourself that you should always consider and which to the Golden Hammer coder will always suck:
- There’s an existing product that serves most of the customer’s needs. Don’t re-write it. You couldn’t possibly make it economically viable.
- You (as a person or an organisation) don’t have the skills that it takes: let someone more experienced do it. They will do a better job, and probably cheaper too.
- Don’t solve it with software at all. That’s right: just keep doing it by hand.
Being passionate about coding is already a double-edged sword, but being in love with a language or framework is positively weird. I have been there myself with GWT , but in the end you’ve got to admit that even the coolest tech is just a tool, just as the software we’re building with it is a means to an end. I can’t really identify with job descriptions that ask for people “passionate about Java”. Sorry, but I’m passionate about making software, not about Java. I wouldn’t shed a single tear if the world switched to Kotlin overnight. Well, tears of joy perhaps.
Elegant delegates in Kotlin
Kotlin has given us some really killer features . Some are obviously useful (null safety), while others come with a warning, like operator overloading and extension functions. One such ‘handle-with-care’ feature is the language support for delegation...
15.11.2017 | 5 Minuten Lesezeit
When anti-patterns become a pattern
There are plenty of learning resources on software best practices. Sprinkled in between all the well-intended advice are warnings about common pitfalls. We could do with a lot more of these warnings and think about why we keep doing the same things wrong...
27.9.2017 | 6 Minuten Lesezeit
The most useless knowledge of all
There are things a programmer needs to know, no excuses. There are things you can’t possibly all remember, so it’s fine to look them up when needed. There is the business domain the software touches on that you need to know. And then there’s knowing...
10.9.2017 | 5 Minuten Lesezeit
Not everything that is vital is also your core business
Large software projects have many vital concerns, such as authentication and authorization. Despite the wealth of available libraries in the Java ecosystem we seem to be re-inventing the wheel far too often. Keep the focus on the core business of your...
- Software architecture
16.8.2017 | 5 Minuten Lesezeit
In defence of pedantic tools
Outline We aim to please the customer at short notice and always overestimate our capacity to comprehend a system as it gets more complex. That’s a recipe for technical debt. The antidote to this psychological shortfall is more team discipline in writing...
- Agile methods
2.8.2017 | 7 Minuten Lesezeit
Mocks or the real thing? Tips for better unit testing
Recently I had to bone up on some of the new features in Mockito 2 and Powermock , though more out of necessity than from genuine curiosity. Powermock and Mockito 2 let you fake static methods, final classes and even constructor calls, but this has ...
- Agile methods
16.7.2017 | 8 Minuten Lesezeit
Essentialism for developers
Essentialism – the Disciplined Pursuit of Less by Greg McKeown is a book with an essential message: much of life is irrelevant distraction and we would all be happier and more productive if we learned to strive for less, but better. I encourage you ...
2.7.2017 | 8 Minuten Lesezeit
The vicious circle of bad test code and how to break it
SUMMARY Compared to the great advances in programming languages and tools, the day-to-day practice of how we actually code is messier than it should be. Especially for long running and complex products building things right is just as important as building...
- Agile methods
6.6.2017 | 9 Minuten Lesezeit
CRUD operations on Spring REST resources with Kotlin
In this practical, hands-on post I would like to share some of my experience in building REST services wih JSON and Spring(Boot) using Kotlin. All examples can be transferred to Java, and if you use the indispensable Lombok library it doesn’t even look...
2.4.2017 | 7 Minuten Lesezeit
Integration testing strategies for Spring Boot microservices part 2
This is the second part of my earlier post about strategies for integration-testing Spring Boot applications that consist of multiple (rest) services. You can find the accompanying sample application in my gitlab account: git clone firstname.lastname@example.org:jsprengers...
27.2.2017 | 8 Minuten Lesezeit
Integration testing strategies for Spring Boot microservices
SUMMARY: Unit tests are a necessary condition to clean code, but today’s convention-over-configuration frameworks like Spring Boot are often used to build applications consisting of multiple services. You need some way of ensuring that the parts are ...
13.2.2017 | 9 Minuten Lesezeit
Web frameworks and how to survive them
SUMMARY: Frameworks that help build the web apps of tomorrow must keep up with all powerful new technology there is on offer. At some point your application has to adapt, and that is never a painless process. You can avoid a total rewrite however if ...
12.1.2017 | 8 Minuten Lesezeit
Kotlin’s killer features
SUMMARY: Kotlin is a new JVM language fully interoperable with Java bytecode. It is clearly inspired by Scala, but has a different design philosophy, a much gentler learning curve and some really helpful features like null-safe types. The Importance ...
3.4.2016 | 10 Minuten Lesezeit
Caching de luxe with Spring and Guava
Summary We generally don’t optimize expensive operations in code until they create a bottleneck. In some of these cases you could benefit a lot from caching such data. The Spring solution is non-intrusive, highly configurable yet easy to set up, and ...
14.3.2016 | 13 Minuten Lesezeit
Sensible mutation testing: don’t go on a killing spree
This is a follow-up to my earlier post about mutation testing (MT). To recap: MT helps you ensure that your unit tests are any good. The framework manipulates your compiled code by inserting small changes (mutants). It then re-runs your tests and expects...
26.2.2016 | 6 Minuten Lesezeit
Mutation Testing: Watching the Watchmen
You can’t do without automated (unit) tests if you want to stay on top of the ever increasing complexity of software projects. A mutation testing framework ‘watches the watchmen’ by inserting small changes into your compiled byte code and then validating...
25.1.2016 | 7 Minuten Lesezeit
Dein Job bei codecentric?
Agile Developer & Consultant (w/d/m)
An allen Standorten
Gemeinsam bessere Projekte umsetzen
Wir helfen Deinem Unternehmen
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Do you still have questions? Just send me a message.