Hammer Time

Whenever anyone gets caught up with, or overly excited about, a software product, design pattern, or piece of technology, the phrase most often used to warn us over-using it is:

To a man¹ with a hammer, everything looks like a nail

It’s a tired and worn out phrase but, on the surface at least, it seems like good advice. One tool cannot do all jobs, there are no silver bullets. It’s not wise to artificially constrain your effort by starting out with an inappropriate implement.

But how can you know ahead of time? Often the people using the phrase are doing so because they have an equally biased view of the tool. An unhealthy negative bias can be as bad as an unhealthy positive one. Delivering good software is never easy. If it was people like me wouldn’t get to piss and moan on the internet about how difficult our lives are.

For example, let’s say you promote the use of your favourite tool for a particular problem. Maybe there’s a bit of a debate, but your charm and persuasive logic wins the day and it gets accepted. Congratulations.

At a certain point things are going to get tough: you will come to understand nuances in the requirements that don’t quite fit the perfect model you had in your head and you will encounter bugs or mismatches in some underlying component that had previously been hidden beneath a useful abstraction. Life will become troublesome. It always does. It might be the tool or it might just be the way of things.

I’ve seen hundreds of projects in difficulty. In most of these the tool gets blamed rather quickly. Sometimes the initiator of the tool also comes in for a certain amount of criticism. Yet when you press the detractors for more detail it turns out that they actually just prefer a different tool. Tool preference isn’t very helpful in answering the question. The fact of the matter is most failing projects sow the seeds of their destruction long before tools get implemented - mostly they fail due to poor communication (expectations, ambitions, team size, someone smoking a little wonka wonka when drawing up the plans).

It’s also ridiculously easy to produce inefficient or suboptimal designs. Sometimes this is lack of skills, sometimes lack of time, and sometimes because it’s all done up-front based on some high-level wishful thinking. Add poor communication to poor design and you have everything you need to know about corporate IT over the last ten years.

But it’s not chaos everywhere. Some companies, notably big online outfits like Amazon and Ebay, manage to do quite extraordinary things with IT. I am reliably informed these companies are staffed with human beings, so I assume they are not immune to poor communication and a little wonka wonka smoking in the marketing department. I spend a lot of time reading the tweets, blogs and web casts of the geekforce in these companies and two things strike me: Firstly, and most obviously, they are smart people. They have a healthy attitude to design and architecture such that they are confident solving problems as they go, rather than all up front. And secondly they have quite strident views about the tools they use.

Contrastingly, the world of traditional corporate IT has become a nervy kind of place. Nobody wants to stand up and make a scene when it comes to tool choice. A CEO friend of mine told me a couple of weeks ago that, in his experience, when board members consider options for delivering a new software project they surprisingly aren’t ignorant of the major discrepancies between their own IT capability and that of their modern internet rivals. But, faced with the choice of hiring a bunch of clearly capable people pitching a bespoke developed solution with some open-source components, and a large vendor they have heard of pitching their “full stack platform” they will always agree to fund what they perceive to be the least-risk approach and plump for the big vendor, even though they know this has rarely, if ever, worked for them in the past. Big businesses these days all want to be Amazon but find it hard to let go of the comfort blanket they think they get from major software vendors.

That’s worth pondering for a moment. Big companies with poor IT can make knowingly bad decisions out of fear. They would rather partner with a plausible but technically incompetent consultancy than a technically credible alternative that doesn’t dress as well.

This fear of perceived risk has affected me many times in the past. The new project starts and the consultants and the big vendor products come. Wary of being seen as the man with the hammer I kept personal partialities to myself. I got on with doing the best I could. Make the unsuitable hulk work, whilst diligently raising and managing issues. But frankly it’s not a healthy way to live. If you keep your mouth shut the one thing you can count on is that you’ll get to work with the tools you deserve.

Tools aren’t just blobs of software; they represent the design philosophies and all round smartness of the teams that made them. Paul Graham wrote a good piece years ago about how certain choices (Lisp in his case) automatically led to hiring smarter people, because smart people gravitate to the best tools. And the reverse is also true. Below average people are drawn to the big hulking products. You won’t just get the tool you deserve, you’ll get the co-workers too.

Some time back I was thinking about the whole hammer concept and how one really needs to promote good design first, and then choose the tools afterwards. Because that’s the accepted logic, right? It’s what we got told in college. It has a whole stage to itself in the waterfall delivery model. Ah. Maybe that’s part of the problem. Because I’m not sure the world is that simple. All designs have to compromise to some extent to fit the chosen tool. This is even true if you are contemplating a ground up build. Firstly there are those inevitable small scale compromises due to language constraints and thereafter your design itself becomes an implied, and potentially obstreperous, participant at all future requirements meetings.

My change of heart came about because of my problem.

This is a good time to bring up my problem.

I love Rails. Every time I write Rails code I feel energised. It puts me in charge of all the value-producing stuff and handles all the web and database drudgery for me. It contains layers upon layers of breathtaking elegance and, like Jack Nicholson in As Good As It Gets, it makes “me want to be a better man”, or coder at least. Rails, for me, has made writing software cool again. I love other stuff too: I love MySQL, I love node.js, I love Python, Django, I love couchdb, REST, Neo4j , MongoDB, I love jQuery, Git, the JSON format, Riak, JavaSpaces, I could go on. And here’s what struck me - that’s a pretty fucking awesome set of hammers.

But ignore the actual hammers. The fact is I have developed my peculiar list through building software and having conversations with other people - people who suffer from a similar tool-focussed obsession, people who get excited about a tool because of its simplicity, design, usefulness in many circumstances. When I meet smart people and they like stuff, I want to know why. I like to know which of my hammers they don’t like.

Sometimes it’s hard to say why I love one tool over another. Just like real love, when you know, you just know.

Loving a tool does not mean always using it of course. Much as I love Ruby I rarely recommend that enterprise clients use it in production. Using a tool for the long term is about more than it’s functional fit, there has to be an organisational fit. But not a fit to the dreaded “corporate standards”. If promoted the lazy idea that beautiful logical models should be overlaid onto the corporately approved ExpensiveWise BloatBus 2000, I would certainly avoid being accused of carrying a hammer before me, but I would also be perpetuating the enterprise malaise that drives us all insane. Not to mention the obvious contradiction that starting a project with “the corporate standard” environment is hammer-fixation of the worst kind.

By all means be aware of pushing a tool too far, that kind of goes without saying. If you have only one tool suggestion for literally everything, then you do have something of an issue. But if you like lots of tools and you’re very passionate about using them then I would go so far as to suggest that it’s probably not you that has the problem.

Design will always be a matter of harmonising what you need with the paradigms, patterns and features a tool can support. Corporate enterprises are slow beasts; they come up for air to make decisions about technology strategy only once in a while. They have to because once they’ve sunk a big chunk of cash into one platform there’s an organisational pressure to show some return on the investment. Normally it’s only after the last CTO gets fired and a new one comes in that there’s an opportunity to reassess things.

But times are changing. There’s an almost constant refrain from the business these days asking what exactly it is that Amazon does that they don’t. What exactly is it that enables Amazon to maintain awe inspiring levels of uptime and responsiveness and make changes to their business model and provide a great user experience. How have customers developed such an unshakable faith in a relatively new brand?

Unfortunately few businesses have made the link between their current state and the regular appearance of the Scooby Doo van in the car park.

Tools alone aren’t the whole answer, but simpler tools that do a few things well are a big part of it because they mandate smaller teams and smarter ways of working. They are also easier to measure and to change when they don’t quite fit (hey, I never said the tool you love would always be the right one).

Designs are people things. They come and go and require constant attention. Tools are the enablers of good design so if you love some then don’t keep quiet about it.

Notes

1. Please note that Maslow’s quotations almost universally use the male form here. Not be accused of sexism I should point out that it’s probably not a purely masculine trait. Though now that I think about it, it probably is.

2. The painting above, used with the artist’s permission, is called “The Hammer” by Steven Kenny, part of his 2009 collection. I highly recommend checking out his site. There are some really quite beautiful and haunting works there. As he says “The world I depict is one where interdependencies prosper and hierarchies crumble”