Why Do We Have So Many Screwdrivers?

April 30, 2006

Jon Raynor added this comment to my previous post about keeping up with the pace of change in software development:

The IT field is basically a quagmire. It's better to accept that fact right away or move on to a different field. I guess someday I wish for Utopia where I won't be obsoleted when I get out of bed each and every morning.

The industry needs to stop running around like a chicken with its head cut off trying to find the next big thing. The tools constantly change, but yet they do the same thing, create code to run on machines. First we get a screwdriver and learn how to use it. Then out comes the newdriver, different than the screwdriver, but does the same thing. Then out comes the phewdriver which is totally different than the screw and new driver but performs the same function of both previous tools.

It's an interesting observation. I'm far from a handyman, but even I own many different screwdrivers: different sizes, different tips, different lengths. They're all performing the same job-- screwing*-- but each one is uniquely useful in the right scenario. I'd hate to throw out all the screwdrivers I own and opt for a one-size-fits-all approach. Sure, I may choose the standard screwdriver 90 percent of the time, but what about that other ten percent?

So a case can be made for having multiple languages and multiple tools, redundancies and all.

However, software developers are awfully eager to throw out existing tools for new ones. Unfortunately, these decisions are often based on myth and wishful thinking, and the decisions are typically made in favor of whatever the hot new thing of the moment is. Here are two mistakes that I see a lot:

1. Let's buy this whiz-bang power screwdriver that will double our productivity.

A silver bullet brand screwdriver, if you will. Just replace the word "Ada" with "Ruby", below:

One of the most touted recent developments is Ada, a general-purpose high-level language of the 1980's. Ada not only reflects evolutionary improvements in language concepts, but indeed embodies features to encourage modern design and modularization. Perhaps the Ada philosophy is more of an advance than the Ada language, for it is the philosophy of modularization, of abstract data types, of hierarchical structuring. Ada is over-rich, a natural result of the process by which requirements were laid on its design. That is not fatal, for subsetted working vocabularies can solve the learning problem, and hardware advances will give us the cheap MIPS to pay for the compiling costs. Advancing the structuring of software systems is indeed a very good use for the increased MIPS our dollars will buy. Operating systems, loudly decried in the 1960's for their memory and cycle costs, have proved to be an excellent form in which to use some of the MIPS and cheap memory bytes of the past hardware surge.

Nevertheless, Ada will not prove to be the silver bullet that slays the software productivity monster. It is, after all, just another high-level language, and the biggest payoff from such languages came from the first transition -- the transition up from the accidental complexities of the machine into the more abstract statement of step-by-step solutions. Once those accidents have been removed, the remaining ones will be smaller, and the payoff from their removal will surely be less.

I predict that a decade from now, when the effectiveness of Ada is assessed, it will be seen to have made a substantial difference, but not because of any particular language feature, nor indeed because of all of them combined. Neither will the new Ada environments prove to be the cause of the improvements. Ada's greatest contribution will be that switching to it occasioned training programmers in modern software-design techniques.

2. This screwdriver is for amateurs and hacks. We should buy a newer, more professional screwdriver.

David Megginson notes the self-perpetuating cycle of successful programming languages:

• Elite (guru) developers notice too many riff-raff using their current programming language, and start looking for something that will distinguish them better from their mediocre colleagues.
• Elite developers take their shopping list of current annoyances and look for a new, little-known language that apparently has fewer of them.
• Elite developers start to drive the development of the new language, contributing code, writing libraries, etc., then evangelize the new language.
• Sub-elite (senior) developers follow the elite developers to the new language, creating a market for books, training, etc., and also accelerating the development and testing of the language.
• Sub-elite developers, who have huge influence (elite developers tend to work in isolation on research projects rather than on production development teams), begin pushing for the new language in the workplace.
• The huge mass of regular developers realize that they have to start buying books and taking courses to learn a new language.
• Elite developers notice too many riff-raff using their current programming language, and start looking for something that will distinguish them better from their mediocre colleagues.

It's OK to add a new screwdriver to your toolkit every few years. But make sure you're adding it for the right reasons.

* Yes, it's still funny.