Doing good work with bad tools

Charlie Parker was one of the greatest jazz musicians. But unlike most artists, he had a cavalier attitude toward his equipment. He would pawn his saxophone for drug money and show up for a concert without an instrument. He assumed that he could always borrow a saxophone at the last minute. He even used a plastic saxophone for one concert. Parker could take a cheap piece of plastic and make it sound good.

Good equipment helps. I’ve played cheap saxophones and professional quality saxophones, and I much prefer the latter. But a good sax didn’t make me sound like Charlie Parker, nor did a cheap sax make Charlie Parker sound like me. A poor craftsman blames his tools.

For centuries people have searched for the secret of Stradivarius violins. What did Antonio Stradivari do to create his legendary instruments? Was there something special about the wood he used? Something special about the varnish? A new theory says that there was nothing unusual about the materials he used and that he simply did excellent work.

It’s hard to think of a worse programming environment than DOS batch files. But I worked with someone who was able to do amazing things with batch files.

Hugh MacLeod calls it “hiding behind pillars” when you think you must have the best tools before you can work. He summarizes hiding behind pillars this way:

The more talen­ted some­body is, the less they need the props. Mee­ting a per­son who wrote a mas­ter­piece on the back of a deli menu would not sur­prise me. Mee­ting a per­son who wrote a mas­ter­piece with a sil­ver Car­tier foun­tain pen on an anti­que wri­ting table in an airy SoHo loft would SERIOUSLY sur­prise me.

Related posts:

Thomas Edison’s fire
Too much time on their hands?
Redbelt problem solving

13 thoughts on “Doing good work with bad tools

  1. Hi John,

    “But I worked with someone who was able to do amazing things with batch files.”

    but how much effort did he expend in doing this?

    Would it just not be better if that same person had switched to better tools (if available) and done the same amazing things with better tools with less effort?

    Quality of tools makes a difference.

  2. I understand your comment about using batch files. This kind of thing could be a stunt, going to great effort to avoid using the right tool for the job. But in this case, the developer I mentioned primarily developed C++ applications. Automation wasn’t his main job. But when he needed to do some automation he took a tool he already knew and solved our problem quickly and elegantly.

  3. One of my hobbies is painting. When I started a could not tell the difference between low and high quality paints and brushes, but as my skills improved I found there really is a difference if you are skillful enough to take advantage of it. The best of materials do not help without the skills and craftsmanship to make best use of then, and the same should certainly apply to programming.

    PS: Charlie Parker’s plastic saxophone is on display at the Kansas City Jazz Museum, a wonderful place to visit should you get the opportunity.

  4. ‘I don’t call it “hiding behind pillars”. I call it “standing on the shoulders of giants”.’

    The problem with standing on the shoulders of giants is that often your reach and destination are decided by that giant.

  5. “The problem with standing on the shoulders of giants is that often your reach and destination are decided by that giant.”

    On the other hand, if you’re standing on the right giant, you can produce something as elegant as calculus!

    While the best craftsmen can do wonderful things with the poorest of tools–and will do so, when that is all they have–the best craftsmen also appreciate good tools when those tools are available. In some cases, a craftsman will use a poor tool to make a better one!

  6. “In some cases, a craftsman will use a poor tool to make a better one!”

    I think the important point to take aways isn’t that you shouldn’t use nice, time saving advanced tools, but to realize that they may limit your easily reached solutions in non-obvious ways. It’s important to step back and make sure we aren’t going down the route of path dependence and lock-in. Neal Stephenson wrote an interesting article on this at slate:

  7. There’s a reverse spin to this, too. In 35 years of software work I have thrice encountered groups who are so enamoured of their vintage tools that they’ll systematically reject any consideration of alternatives. I’ve seen this happen in two cases where the group will reject business they cannot do with their tool- and mind-set. Perhaps that works some of the time but there are missed opportunities there … I’m not saying EVERY new tool id a good idea — object-oriented programming being one suspect — but doing stuff in assembly or C or shell all the time hes its drawbacks.

  8. As we struggled to last night with our Celestron telescope to get a proper aim on THE FREAKING SUN for a look at the Transit of Venus, we marveled at the thought of Galileo discovering the moons of Jupiter with his homemade 16th century technology.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>