Efficiency can be lost on code snobs

At my local Ace hardware store, circular saws sit near the registers to tempt impulse buyers. When Ace sells you that saw, they've also got you for blades, safety glasses, and handy little accessories. But Ace isn't the only beneficiary in this "sell the saw, sell the store" arrangement. Simply having the saw turns some neglected, avoided projects into adventures. For the buyer, the saw is an inspiration: "Get the saw, fix the house."

The circular saws of software development are dynamic languages such as Perl, Python, PHP, and JavaScript, as well as RAD (rapid application development) tools such as Visual Studio. The better of these allow you to leap straight to solving problems without paying your dues by learning the underlying OS, low-level APIs, and networking architecture. There's no studying of patterns, models, or methods. It's like buying lumber, nails, and a saw without deep study in the properties of wood and fasteners. A carpenter would be aghast that you're not an expert at operating a handsaw. A true developer will gossip about you for using a PHP database class without knowing much about how the database on the other end works. Both will warn that you're courting disaster.

We'll always need expert tools, structured processes, and people who can ply both to create bulletproof apps. But we also need tools that allow us to attack projects that would otherwise be out of reach. In modern computing, the limit of one's reach is marked by the limit of one's understanding of the platform and user environment. For a large class of applications, that need not be so. Most of the problems we solve every day aren't nearly as complicated as popular tools, languages, and frameworks.

I'm reminded of the near-miracles I've worked in JavaScript and shell scripts, and even in quick-and-dirty C or C++. I've knowingly made things harder for myself by setting aside these tools as cheats, shortcuts suitable only for prototyping. As I look at my straining bookshelves of volumes on .Net and Java, I'm reminded of the vast numbers of problems I haven't approached because I insist on using the right tools the proper way. Being a code snob has distinct disadvantages.

Look, a fence made by a first-timer is a successful project if it remains standing and looks presentable; it's better than letting the old fence rot because it's more of a job than you can handle. Just go buy your saw. Read the safety instructions, buy a little more lumber than you need, and pick up one of those skinny Time Life books about home repair and improvement.

Technique and process are irrelevant unless your point is to impress someone who does for a living what you plan to try. Given sufficiently fast computers, prototypes that work to spec are potentially deployable applications. One project that helped restore my perspective is an administrative tool I created for OS X Server. It allows me to send magic packets to machines in my lab while I'm on the road. The right way would have been to write this entirely in Cocoa, Apple's native framework. The next best way would have been to write it all in Java. I'm sure I could have used AppleScript, a language that I cannot describe in publishable terms. Maybe I should have used Java. In the end, I wrote a shell script that calls into AppleScript for its GUI. It worked the first time. Now I'm heading for that fence. I'm on a roll.

Tom Yager is technical director of the InfoWorld Test Center.