Monthly Archives: September 2010

Squeaky doors

I work (remotely) with a senior development manager. His office door squeaks.

I know that he’s been in that office for several years, yet every time we have a video conference — multiple times each week — I’m greeted by a series of loud creaks as each physical participant enters the room.

I’m pretty sure he no longer notices the squeaky office door; perhaps it’s even a charming, reassuring quirk of his environment. Maybe he jokes “oh yes, you get used to it”, or “haha, one day I’ll bring in some oil”.

I notice the squeaky door. In fact, I’m a little surprised that anyone could ignore it for so long.

The squeaky door is, of course, a parable about bad tools or environments. (It’s also absolutely real: if I wasn’t a thousand miles away, I would have oiled that door a long time ago!)

When I moved into my shared office as a new PhD student, many years ago, the door squeaked. When I went to get coffee it would squeak. Running down the hall for a printout? Squeak, squeak. The very next day I brought in a small bottle of oil, and two minutes later the door was swinging silently.

It pays dividends to spend a little time working on removing the frictions we encounter every day: from oiling hinges, to moving furniture, all the way to switching build tools or deciding to work remotely. (I’d call a frustrating commute a big friction!)


I’ve always had a little bit of an obsession with tools. Building, buying, using, admiring.

All kinds of tools. I have an attachment to the shiny ones — pocket knives, clicking open and fitting the hand; watches; firearms, steel reciprocating and rotating under huge stresses with minuscule tolerances. The dirty, heavy ones, too; these were part of my youth. Large metalworking lathes, striking off big curls of swarf; old drill presses with the chuck key attached by a chain, carefully positioned so that the safety guard would interfere if the chuck key were accidentally left in place.


These all have some things in common: they’re built with singularity of purpose; they have been refined over years (sometimes millennia); and, whilst they demand respect from the user (these are not toys), their workings and affordances are obvious to their intended audience. There is no mollycoddling, no wizards, no DRM.

Having an ample collection of tools is a joy. With the right tool, any job is easy. Without it, one struggles, messes up, gets dirty, gets frustrated.

Yesterday I changed a couple of wheels on my truck. Each wheel weighs perhaps 70lb with the tire mounted.

My jack stands were too large for the restricted space around each jacking point, so I had to do one wheel at a time, using just my shop jack. The lever on the jack was too short, so I had to stretch under the rear of the (elevated!) truck to work it. Lifting the wheels into position on my own was a challenge — they are 33″ across and at least a foot deep. My torque wrench was at the limits of its range, and still needed help from my breaker bar extension. Even my heavy-duty impact wrench had difficulty breaking the factory lug nuts loose.

A job that would have been easy on a small car turned out to be a sweaty, dirty mess. Inadequate tools. Lesson learned.

Making tools as you need them is an important skill, and an important attitude. Machinists, mechanics, woodworkers… these people are all used to building jigs and tools to make their jobs possible, or to make difficult tasks repeatable. I am often surprised at the number of software developers who only use tools, never making their own. They will perform tiresome tasks by hand because Visual Studio doesn’t have a plugin for it, or because their shell isn’t up to the task. They will allow their existing tools to dictate their technology selection, because it never occurs to them to make their own. Perhaps they aren’t lazy enough (laziness being a chief virtue of a programmer), or maybe they have a high tolerance for frustration. Me, I get annoyed every time I have to use Remote Desktop to manually install a test environment. “You mean I have to use the mouse?!”

Programming tools are one of the few pieces of software for which you, the developer, are also the end user: scratching an itch. It should be second nature to build them; even to spend half or more of your time building tools to do your work for you. (From one perspective, this is what macros are all about.)

I don’t just mean making new tools, either: we should constantly look for existing processes, tools, systems, and components which are inadequate, no longer fit, or could be expanded to make our lives better, and replace them. These are the levers by which we move the world: shouldn’t we constantly look for longer ones?

One of the most frustrating work situations I’ve encountered is when my two previous points collided: having bad tools, and entrenched organizational forces that prevented the introduction of new, better ways of doing things. Few within the organization were aware of the alternatives, and the cost of changing was high, so hundreds or thousands of people plodded on each day, doing the software equivalent of building pyramids out of high-tech bricks, but moving them with rolling logs and frayed rope.

There’s no good way out of this situation: nobody can justify the disruption of a major shift in tools to upper management — the old way works, so it’s hard to even suggest it. If you’re lucky, some brave soul will do their best to incrementally improve the old technology: low-profile rolling logs, sharper stone axes. “Crappy Tool v2.0, Now With Slightly Less Suck”. There is no leader to drive the change past the entrenched resistance, because nobody who can justify the expense actually suffers from the bad tools.

The only solution, I think, is to avoid stagnation at all costs, because stagnation eventually becomes impossible to escape. Just as with engineering debt, if you build up too much it can be very difficult to shift. Be mindful of over-attachment to old tools, and constantly strive to use the best. Re-evaluate, re-implement, and replace.

And don’t ever hire anyone who doesn’t build their own tools.

Time for a new technical blog

The barrier to entry of my extremely clunky old blog was preventing me from writing… so here’s a new one. If only all things in life were so easy. Over time I might scavenge and re-import good stuff from the old into the new, but don’t count on it.

What’s in a name? As those who’ve worked with me are aware, I’m fond of the old saw that once you’re done with the first 80% of making something (particularly software), you’ve still got the last 80% to go. I aim to cover the whole 160% here.

Expect neat little code snippets, thoughts on user experience, and grand commentary on the distortion of Alexander’s architectural pattern language into the horror that is the modern software patterns movement. Or just stuff that’s too long for Twitter.