I seem to be writing a series of posts on the subject of folly, lately.  Here is another in the series.  One of the most ludicrous things I see or hear in business plans or in corporate planning sessions is the idea that the software can be written, once and for all and then the company spend the rest of its existence simply using the software to make money.  The software development engineers can be made redundant and the company can simply operate the software for all time, from a lower cost base.

This is nonsense for the same reason that believing all the laws can be made and then all the politicians sent home is nonsense.  Conditions will always change.  The competitive landscape will keep changing.  Expectations of what your company does will keep changing.  The platforms that the software runs on will come and go.  It’s a moving target.  The software is never finished.  You can’t pretend that the world your software operates in will stay static and unchanged, just because you have declared your final release finished.

Imagine if Henry Ford had declared the state of automobile design to be complete, after the release of the Ford model T.  Where would we be today?  Where would Ford be, if they were still trying to market the model T up against the Audi R8s of the world?

The fact is that anything complex we design, but especially software, is the embodiment of the skills and experience of the makers.  Without those makers, it becomes a museum piece.  Nobody else knows fully what it can do, what it can’t and how to change it.  The most important piece of any large and complex software programme is the understanding that went into it, the mental record of all the design decisions and compromises that resides only in the wet ware memory of the developers, the intricate mental model of how all the current and future pieces should go together and work together and the heart and soul of the people that froze their understanding into executable code in the first place.

On the balance sheet, the software “asset” is valued, as if the compiled binary had any intrinsic worth.  That is a little like valuing a ventriloquist act on the basis of the cost of the dummy, ignoring and devaluing the ventriloquist.  In fact, running the software forever, without the software developers that created it, is a little like buying a ventriloquist’s dummy alone and expecting it to speak.

So many business plans I have seen have utterly ignored the need to maintain the software they have (it won’t be flawless…there are always defects and removing them protects the value of the software).  They also fail to factor in the cost of keeping their software competitive and relevant in the market in which they operate.  They fail to factor in the cost of renewing the technology underlying the design, at intervals, because the platforms become obsolete.  All of these hidden costs have to be included in the price that is charged for the software, but frequently aren’t.

Finally, they never account for the cost of needing to build a better one, next year, and every subsequent year, ad infinitum.  That’s the only way you can proceed and grow.  You have to learn from your first efforts and make an improved one.  The market accepts no less.  That means you also have to retain the people that made the first one, or all the experience you need to make a better second version simply walks out the door.

I’ve seen many companies attempt to make an improved version of a software application using people that had no involvement whatsoever in making the first one.  That results in another first effort, not an improved, evolved, better-designed second version.  The tendency for companies to fire or fail to retain the people that made earlier versions is so common that it’s ridiculous.  Every few years, a new bunch of people that have no idea of what went into the earlier version have a go at making a new version.  The result is something often less good than the thing it replaces.  They’re virtually starting from scratch, after all.  They’re no smarter about solving the problem than the first crew were, when they started.  They’re also a lot less educated about the problem domain than the people that they replaced.

So if you ever see a plan to make the software, and then fire all the developers, or to rewrite the software with newer, younger, smarter people, run a mile.  It is pure fiction and people that execute on such plans are delusional or cynical.  Those plans never work out as promised, in reality.