I am a software contractor. I am often called a “consultant” but I never use this term because the work I do rarely fits that definition. A consultant is a person whom you would hire on the presumption that he or she knows more about some subject than you do, and from whom you are seeking advice and guidance, whereas a contractor is someone you hire to fill a well-defined role in a project that is already planned and underway. The disturbing thing that I’ve noticed in recent years is that my clients seem to use an awful lot of contractors, usually because what they really needed at the start of the project was a consultant that they never hired.

Here’s a typical scenario that I walk into these days. I am one of the later contractors hired on a project that is already months late. Project management believes that the software is already mostly built and merely weeks away from delivery, and the reason I’m being brought in is to tie up the loose ends that management has been nervously noticing more and more of lately. After about two weeks I’ve assessed the project and I privately predict that we might deliver an extremely stripped-down version in perhaps six months. I don’t say this out loud, of course, because management is firmly convinced that we are delivering the whole thing in what by now is merely a few weeks. So I just quietly work on whatever I was assigned.

The weeks pass, during which it becomes increasingly apparent that we are not going to deliver a project that had been originally scheduled for delivery six months ago, and which has been underway for over a year. A shakeup happens, during which the client’s employees sometimes change roles or jobs. Upper management suddenly discovers that much of the project is not even designed yet, much less implemented. A massively scaled-back version is called for and promised for delivery in six months.

The six months wear on. Programmers are added, one at a time, almost up to the release date. At the end of the six months we deliver a version that is even more greatly scaled back than I had imagined, usually along with an as-yet-unresolved bug list.

I suppose someone might call this a success, since something was ultimately delivered, but by any reasonable business standard it is not. Failure is the norm in new custom software development, and it always has been. Estimates of the failure rate over the past several decades range from 50% to 70%, but regardless of the precise number, it’s way up there. There are actually many books, including some very good ones, on the subject of software failure, its causes, and its remedies. Do an online search on “software project failure” and you’ll find dozens of pages of links to blogs and articles on the subject.

So why am I discussing this? Well it seems to me that there are many people undertaking the risky business of custom software development with considerably more optimism than their circumstances warrant. The vast majority of custom software undertakings that I see seem to be managed by people with no technical degrees or experience in computer science or software development. Most of them seem to have a vastly simplistic view of what is involved. That view goes something like this:

1. Hire a manager to oversee the project. No technical experience required or even preferred.
2. Provide the manager with project management software or perhaps just a spreadsheet.
3. Model the project as merely a set of user-visible features, such as a set of screens for example.
4. Lay out those features on a time line.
5. Hire a bunch of software contractors and assign the features to them.
6. Knock out the features according to the schedule.

If only it were that simple. I see this model in use all the time and it is the closest thing that I can imagine to a prescription for guaranteed failure while maintaining the illusion of success right up to the bitter end. (Who can argue with the manager whose schedule shows all the lovely benchmarks being hit, at least initially?)

So why does this B-school model fail? Very simple. The model does not take into account the true nature of building a successful, maintainable, deliverable software product. My favorite way of explaining this is through an analogy. And yes I realize the world is full of bad analogies, but I believe this is a good one.

Suppose you are building a custom house, and you use the model that I see being used on software projects everywhere. It would look like this:

1. Hire a manager to oversee the project. No construction experience required or even preferred.
2. Provide the manager with project management software or perhaps just a spreadsheet.
3. Model the house as nothing more than a set of rooms, and have an artist draw an artist’s conception of each one.
4. Lay out those rooms on a time line.
5. Hire a bunch of contractors (carpenters and a plumber or electrician or two) and assign the features to them.
6. Knock out the rooms according to the schedule.

Notice the absurdity. Few would hire someone with no construction experience as the general contractor for a custom house. Nobody would imagine that a house consists of nothing but a set of rooms (no basement, no central plumbing, heating, or electrical infrastructure, no roof, etc.). Nobody would go straight from an artist’s conception to actual construction without first hiring an architect and producing a blueprint.

So why do people do analogous things when building custom software? That’s our next topic.