I just finished reading a great blog post by Hilton Lipschitz entitled “It Should Only Take You a Few Hours …”. In it, he uses the analogy of a carpenter hired to build a table to explain why software developers can’t slap together a piece of software in a few hours.

In my experience, most people either overestimate or underestimate the difficulty of building software, usually by a significant degree.  People who overestimate tend to be those who actually use the software to do their work.  People who underestimate it tend to be managers and other decision makers who have to pay the bill.  No surprise there.

As a consultant who routinely deals with new clients, a big part of my job is to educate them on the level of effort required to develop a piece of software.  It’s not uncommon for the first consultation to end in disappointment when I inform the client that their new YouTube killer cannot be built for $2,000.

While the disparity between budget and desired outcome is frequently a factor, I think that there are others.

First, because people routinely pay small sums of money for software that has a huge number of features, they estimate the labor that went into the software according to the price they paid.  While they may know that other people also bought that software, the actual scale of sales isn’t evident so they can’t extrapolate the cost of production and thus the amount of labor that went into it.

Star Trek syndrome may also be at play.  By this, I mean the idea that you just tell the computer what you want, and it does that.  Technically, that’s the way it works, but on a much, much lower level than most people realize.  Even with modern GUI, database, etc. toolkits, you still have to give it instructions like “Put the button at coordinates 10, 30.  When it’s clicked, check the first checkbox.  If that’s checked, set this variable.  Check the next checkbox.  If that’s checked, set the other variable.  Open the file.  If that failed, check the error code.  Now display this error message.  If it didn’t fail …”.

Finally, a lot of people never really sit down and document the work processes that they execute every day, trying to account for all of the inconsistencies, errors that may occur, exceptions, etc.  When you’re writing software, particularly custom software for a business, you have to do exactly that.  It’s complex.  There are all kinds of moving parts, and exceptions and inconsistencies abound.  That analysis and documentation process alone can take days, particularly when you have to pull information out of the brains of multiple people who aren’t used to thinking in terms of process.  It’s like asking a baseball pitcher to tell you the exact motions he uses to throw a curve ball.

The next time a client tells me that something can be done in a few hours, I think that I’m going to point them to Hilton Lipschitz’s blog post.