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.
We all know how this Golden Hammer experiment ended up…
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.