I have often wondered why people manage custom software development projects in a way that would seem patently absurd in the development of any other sort of product. I’ve come to believe that it’s because people think that software is soft.

For example there is a dominant software methodology today that claims that you can build a software product by iterating through multiple versions of it, essentially redesigning it on the fly as you build it. Now imagine that I were to propose to you that we build a skyscraper via such an iterative process. According to this methodology we will intentionally refrain from using an architect or creating a blueprint. Rather we will just hire some contractors and set them to work using nothing but artists’ conceptions of the building’s exterior and interior.

Of course you would reject this proposal. Even in the abstract the concept seems preposterous. And if you were to watch people actually building a skyscraper via this technique, you would be staggered by the waste. Imagine the cost of building a quarter of the building and then realizing that the load-bearing walls are in the wrong places, tearing the building down, and starting over. Next time we get a third of the building up before starting over. Eventually the project burns through enough time and money that the financiers start running out of resources and patience and prohibit any more teardowns. After this point, all the remaining design defects, which we will continue to intentionally avoid anticipating by refusing to produce a design on paper, will have to be compensated for somehow. What would such a building look like?

If the above sounds silly to you, then let me assure you that I’ve seen it happen many times, but with a software product rather than a skyscraper as the objective. Why do software project managers engage in such policy? Two reasons, I believe:

1. It seems cheaper to tear down a software product and start over, since there’s no physical material being wasted.
2. The final product, no matter how internally deformed, is regarded as acceptable because you can’t see the awfulness of its underlying structure.

But the reality of the software project is actually very similar to the nightmare of the skyscraper, except that there’s no physical material to discard during the iterations or to disturb your sense of aesthetics when the project is done. Almost everyone has at least a superficial notion of what a skyscraper is supposed to look like, but almost nobody knows what a well-crafted piece of software is supposed to look like, not even most programmers. So your software development staff can deliver the most ungainly piece of work as a final product so long as it has a pretty face, and few will be the wiser.

Software is every bit as solid as the walls of a building. You have to pay people to build both. Once someone has laid the foundations of a software product’s structure, you cannot just move them around without considerable expense. Whether the product’s design is preplanned or not, or whether it is well done or not, programmers cannot simply violate its structure without making things worse. It costs time and money and plenty of them to rip out an existing design and redo it, along with all the software that was built on top of it. And yes, a piece of software can be ugly, and ugliness costs you money – and plenty of it. Just because poorly-built software isn’t visible doesn’t mean that you won’t be paying the consequences of its unwieldy design for years to come.

Software is not soft. There is no reason to approach it any differently than you would approach hardware. So if you’re thinking of undertaking a software development project, I recommend that you contemplate two things:

1. If you wouldn’t build a piece of hardware yourself, maybe you should also consider not building software yourself. Leave it to a professional and make sure whoever you hire can be held accountable, since the success rate even among self-proclaimed pros is not particularly high.
2. If you’re convinced that you can build software, please don’t imagine that it’s any easier than building something whose internal structure you can touch and see. Be prepared to sweat the details and understand the design, just as if you were constructing a building.