Monday, May 11, 2009

Use the Right Tool for the Job

I recently needed to build a series of storage closets in my garage and was able to borrow my son-in-law's nail gun for the task. It was so cool. Having pounded a billion nails into 2x4s over the years I fell in love with my new tool. I can't imaging doing another construction project without it. It was so cool. Just load it up with a stack of nails, turn on the air compressor, press a little button, and THWACK! So cool. It was only later that I learned that according to the U.S. Centers for Disease Control and Prevention there are about 37,000 nail gun injuries a year.

37,000? I didn't know that the industry had sold 37,000 of these puppies! Really, 37,000? I mean... I know that accidents happen and all - but... 37,000? That's 740 per state, 2,500 per major city, 101 a day, or 6 nail gun accidents every year for every Wall-Mart. In the book, Why We Make Mistakes, Joseph Hallinin tells of a man who accidentally shot himself with a nail gun... in the head... twice. Ah, the power of new tools.

Of course nail guns are useful tools when used in the right way at the right time and for the right reasons. Programming languages are useful as well, but choosing the wrong one for the wrong job at the wrong time can be just as smart as shooting yourself in the foot (or head) with a nail gun. I'll leave the C or Java, FORTRAN or COBOL debate for another time. I am frequently approached for an opinion on the use scripting language; such as Perl, PHP, Python, Jython, or Godknowswhat. Typically the conversation goes like this:

proponent: I can write all of the code to launch a nuclear missile counter attack is less than 12 lines of code - wohoo!
me: Does that include comments to make the code decipherable?
proponent: What? Anyone with a spare neuron can easily understand the code?
me: Anyone?
proponent: Shut up!

I once chaired an architecture discussion to determine if outdated client/server application written in dBase III (ok, well it was written with FoxPro, but six of one ...) should be replaced by a shiny new Internet/web based application written in PHP. For those that don't know PHP is an abbreviation of Personal Home Pages - the original purpose for the language. With all of the analytical calmness we could muster we respectfully indicated that PHP would not be our first choice. I think the order of language preference would have been:

Java with HTML/CSS/JavaScript
C# with HTML/CSS/JavaScript
Bailing wire

I'm not suggesting that PHP has no place in a development shop's tool kit - it just shouldn't be used as the primary engine for creating commercial grade, secure, functional code that (and here's the key) will be modified by others for years to come. Scripting languages, as a whole, provide rapid development at a cost of readability. For a moment, divorce yourself from your own preferences, the investment of time, and the cool things you know about your favorite developer tools.

If you think about it, rapid coding and readability are necessarily opposite ends of the scale. COBOL is very readable. Why - because it is as chatty as a pre-teen with a cell phone. Perl and others of its ilk lend themselves to rapid coding because you can create a lot of function with a limited number of characters. To be sure, you can create readable code with Perl, PHP, Python, ANT and others, but most coders just don't. We're in so much of a hurry to get the code to work, and then in so much of a hurry to get to the next thing, we never take the time to make our scripts readable.

To be fair, I've seen some pretty unreadable Java code as well, but typically, we tend to take the time. Scripting languages come and go; with a new one entering the scene every eighteen months. It would be impossible for a leading edge development shop to adopt new languages, train enough staff, deliver new function while maintaining the code base when the underlying language changes that often. Use scripting languages like Perl and ANT and Python when on-going maintenance is likely to be minimal. They are perfect for one-time data conversion utilities. They are also ideal when you need rapid development of small, easy to digest functions (i.e. the original idea behind JavaScript). Think utility. Stay away from scripting languages for any application you set in front of someone else.

Now, I'll wait for the onslaught of objections from the why-not crowd.

Follow by Email