Don't use a Screwdriver as a Hammer

Whichever Engineering discipline you specialise in, you want to build knowledge and experience in a sufficiently rich set of tools so that you can always apply the best tool for any particular job. You want to avoid trying to use a screwdriver when what you really need is a hammer.

Let me illustrate with a story from the Software Engineering world. I once worked with an Engineer I'll call Stan, who was a very smart guy but extremely particular about his choice of tools and technologies. In short, he was a pedantic you-know-what. Stan would get into long-winded arguments with people about why this language or that interpreter were pieces of crap, because he didn't like the lack orthogonality in their syntax, or something else about them offended his sense of style. A good example was the mail-war we had about the language Perl.

I had become a Perl fan at my previous job, when I had used it to simulate and cross-check data transactions between two microprocessors communicating via a shared memory bus. Some problem was causing one of the microprocessors to crash intermittently, and I wanted to rule out the possibility of a shared memory communication corruption being the cause. I instrumented the shared memory bus with a logic analyser, which collected so much data in a fraction of a second that I could never possibly check it all during my remaining lifetime; especially considering that I had other plans to fit into it too. This was in 1990, and I had seen the source for a new fast scripting language interpreter named Perl posted on Usenet, by the same really smart guy who had written the patch utility, and the rn newsreader. I thought it might be worth a look. Perhaps I could whip up a simulator that could process the data and scan for any anomalies. Perl compiled its scripts before executing them, which meant it was much, much faster than other existing scripting languages and perhaps it could wade through the mountain of data before I'd die of frustration. Given that I'd never used Perl before, I was totally floored that I was able to compile and install the interpreter, learn the syntax, write my simulator, run the data through it and verify that the communication protocol was functioning correctly; all in the same afternoon. From that point on, Perl became my tool-of-choice for munging data.

Perl's syntax was, and still is, a dog's breakfast. It combined all the power and elegance of the Borne shell, sed, awk and C in one god-awful soup, which read like the random typos of one of the infinite number of monkeys you never hear about who weren't on their way to producing the script of Hamlet. Powerful: Yes, Elegant, No.

To Stan, Perl was an anathema. And although I understood where he was coming from, he just seemed to be taking his disdain to an unreasonable extreme in despising Perl. To my mind, a great engineer has a toolbox full of different tools at his disposal, and uses whichever tool is best for the job. I could see that there were some jobs for which Perl, despite the inelegance of it's syntax, was the best tool for the job, and it seemed ridiculous to discount it simply because it tended to wear out your $ key. I used the analogy that a tradesman doesn't use a screwdriver as a hammer; he carries a tool box with a screwdriver for screws, and a hammer for nails. And for some jobs, Perl was a hammer. But Stan would not budge, and basically wanted Perl banned from the department. Fortunately Stan wasn't in charge of the department, and when I wanted to write a new build script because the existing Makefile system was proving cumbersome to me, I wrote it in Perl. Stan complained bitterly which caused much trouble for me over this, and I eventually got him off my back by promising that I would rewrite it in Borne shell as soon as I had the spare time. I knew this meant it would never happen, because something else on my to-do list would always be a higher priority than rewriting a perfectly functional script in another language just for the heck of it.

You don't need the perfect tool; just one that's reasonably close in terms of efficiency and effectiveness. We can't specialise in or learn everything, and invariably we all have our own personal tastes and preferences which influence our choice of tools. But it doesn't pay to be pedantic; even when you are preaching flexibility and pragmatism: Imagine my surprise a few weeks later when I found myself in the laboratory needing to hammer something, but unable to find a hammer anywhere. The biggest screwdriver we had was sitting easily accessible on the desk, so I picked it up by the pointy end and used the chunky handle end to whack the item in question into place. I marvelled at the irony of it, but I didn't ever tell Stan. Sometimes the best tool for the job is simply the most easily available one.

---

Social Bookmark this page: