Debunking the duct tape programmer

This is, of course, a far cry from the person who does everything with duct tape, because it's simpler to do so. And it's also a far cry from the person who always follows his/her standard approach, because nobody ever got fired for [using the safe-but-costly approach].

In essence, the duct tape programmer has a safety margin between the smartest he could do, and what he actually does, and uses this safety margin (1) to make the software actually work, because he can avoid stupid errors, and debug the subtle issues that come up, and (2) to make the software ship on time. Not using your most-advanced-yet-poorly-understood techniques does not mean you'd stick to the stone age approach, but that you're perfectly fine with using stone age tools in addition to the fancy-schmancy newfangled stuff where it makes sense.

I, for one, won't Party with Palermo on this. I'm more cautious of people making their money with agile training than with people selling bug tracking systems.

A pal of mine was a consultant for a logistics company serving a large country that's north of the U.S. This company was developing a package tracking system in Java, back around 2000 or so, when "Java" was often a synonym for "Project Failure."

Now, when the whole thing started, I told him that I could knock off a prototype in a week in PHP. Nope, these guys decided to spend five months developing a framework for their application, and then they were going to spend the next month developing the actual app.

Well, six months later, I hear that the predictable outcome had happened: management was shocked to discover that the application took 30 seconds to serve up a page view.

My pal sent me a copy of the app and it was an absolute rat's nest: the kind of project where you use 1500 lines of code to say what you could say in 15. The sheer bulk of the code made it difficult to maintain: and it had poor performance written into it's DNA. The real problem was that this wan an IBM shop that was developing its first webapp, developing its first Java app and... nobody knew what they were doing.

-----

Don't get me wrong. There's nothing wrong with front-loading your design and analysis work... IF YOU KNOW WHAT YOU ARE DOING! In the hands of people who have a holistic view of the application and toolset it's based on, front-loading is a beautiful tool that can make implementation and testing a breeze.

However, because it delays feedback, prolonged analysis doesn't (necessarily) test the ideas behind a design. Bad ideas can get in, and stay in -- nothing challenges the arrogance of the uninformed.

If, on the other hand, you are humble, and "know what you don't know", a rapid prototype can be a powerful way to get some experience, test your ideas, and, who knows, maybe even ship something.

Beautiful.