Recently, Sky continued its series of adaptations of books from Terry Pratchett’s Discworld series by commissioning ‘Going Postal‘. This is a tale of a conman coerced into running the city postal service, locking horns with the dominant competitor who had a monopoly in sending messages using semaphore towers located across the continent (A system whimsically call the ‘Clacks’, a mechanical version of Email).
- Image via Wikipedia
The Clacks system started as a few towers to prototype and demonstrate a communication mechanism as a proof of concept. This prototype never got ‘thrown away’, and instead grew, carrying with it the flaws and problems encountered in its constructions.
The same is true for many software systems. Fred Brookes tells us that you should ‘plan to throw one away‘, as you invariably will have to do this anyway. The escalating costs of maintaining the system built on the prototype will be at least as large as the cost of throwing the system away.
So, what was the attitude of the directors of the ‘Grand Trunk Semaphore Company’ that controlled the Clacks? Grind the system into the ground by cutting corners, scaling down maintenance while subsequently raising charges. This attitude in relation to software systems will be familiar to many onlookers.
This neglect had cause the system to ‘crash’ so frequently that its emerging rival, the post office, had established a foothold in the now substantial niche that was left by these system failures, and was taking substantial business from the ‘Clacks’ company.
The directors called an emergency meeting, in which they invited the chief engineer, Mr George Pony, to advise on fixing the endemic problems precipitated by the years of neglect.
Pony: ”Do you want it fast or cheap or good, gentlemen? The way things have gone, I can only give you one out of three…”
Director: “How soon can we have the Grand Trunk working properly?”
Pony: “Nine Months, shut down”
Director: “Don’t be a fool, man!”
Ring any bells?
The mere use of a software system does not physically wear it out in the same way that use of a mechanical system like the Clacks does. The wear and tear on a software system comes in the form of updates, upgrades, extensions, etc.
Mr Pony goes onto insist on the restoration of the ‘Hour of the dead’, which had been done away with by the management.
Pony: “Could we have the Hour of The Dead back, Mr Gilt?”
Gilt: “I really wish you would use that fanciful term”…”it really does not present the right image”
Pony: “Sorry, sir, but I still need it”
Gilt: “That’s revenue flow we’re talking about. the board won’t be very pleased with me if I-”
‘Pony: “I think I’ve got to insist, Mr Gilt.”
The hour of the dead was a time at which the communication towers were shut down, and simple maintenance performed. Small problems that would eventually lead to large problems were addressed, and the whole system kept manageable.
The same concept can apply on a larger scale with our software system. Consider a ‘Month of the dead’ each year,or an allotted time in our software lifecycle to maintain areas of the system. Technically, we don’t even have to write any code; for example, we can simply document what is out there and identify areas for refactoring/improving.
And that month goes for everyone, requirements gatherers, business analysts, developers and testers to name a few.
