The Software is Finished – Part 1

I have customers who ask “When will the software be finished?”. I have more experienced customers who ask “When will the software be ready to use?”.

Having been writing software since the days of the Motorola M6800 (Motorola’s first microprocessor, programmed in assembly language) I have completed many contracts. As a business I have to also ask “When can we invoice for the software we have written?”. But I can’t think of many software projects that were genuinely “finished”.

Software seems to come to an end when either

a) The use for the system the software is running on disappears.
b) The development of the software has become so tangled and uncontrolled that it is no longer maintainable or useful.

If you take case a) this actually rarely means the software is “finished”. Even in those early 100% assembly code projects that I did later versions of Motorola microprocessors were assembly code compatible with earlier versions (most successful being the upgrade from the M6800 to the M6809 family). Even assembly language that is not of the same family can often be manually ported across to a different CPU if it was originally well written and well commented.

The key to good software is that it must be easy to re-use. You will find it very hard to stay in business if you try to write everything from scratch. If this goal can be achieved then case a) above becomes suprisingly rare. Trying to think of an example where an actual system disappears completely is hard. Perhaps, if the oil runs out and we can’t get any fuel for any internal combustion engine then all the engine management software out there might genuinely be “finished”…..

So that means that case b) is the most common reason for software being “finished”. Case b) must be avoidable in all cases (provided there is awareness of the need to avoid it).

More to follow in next posting.