An ode to tool-first thinking
By Julian Browne on May 17, 2010. Filed Under: architecture, business, delivery, development
To a man1 with a hammer, everything looks like a nail. A well-worn phrase used to alert us to the dangers of getting so caught up with one product or technology that, whatever the problem we are trying to solve, our answer is always to use it. On the surface it seems like good advice. You wouldn’t want to artificially restrain your efforts by choosing a completely inappropriate technology, would you?
But how would you know? Delivering good software is never easy. If it was people like me wouldn’t get to piss and moan on the internet about how hard our lives are.
For example, let’s say you do 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 previously had been comfortably hidden beneath a useful abstraction. Life will become troublesome. 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, which 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 and I am reliably informed they 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 business exec friend of mine told me a couple of weeks ago that when faced with a choice between a bunch of (clearly clever) geeks pitching an open-source solution and a full stack platform from a vendor they have heard of, 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.
This coyness has affected me in the past too. Wary of being seen as the man with the hammer I kept personal partialities to myself 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.
Some time back I was thinking about the whole hammer concept and how one really needs to promote good design 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 phpmyadmin, 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.
Not only that but I have this love-list through conversations with other 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. When it turns out there’s also a smart core team behind the product I have to try it out.
And just like real love, when you know, you just know.
If I took the view that it’s better to design beautiful logical models and then to try and overlay them onto Expensivewise Bloatbus 2000, the approved corporate standard, 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 things 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.
Now don’t get me wrong. 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.
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.
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”