The flip side of my comments from yesterday are definitely the other things that just haven’t changed and really should have done. Spookily I was thinking about this on the way into work this morning (just don’t get me started on how annoying actual cheques are and how internet banking really doesn’t go far enough, OK?) and then during the day Matt Haughey posted this rant about receipts still being paper and how he has to keep the paper copy of the extended warranty for 5 years, else it’s invalid. He has a number of very valid points … so much data is stored in various systems these days. We should really be able to deal with these issues without resorting to using little bits of paper to prove things happened. The problem, though, is one to which so many modern businesses will attest: much as we are great at getting things into systems, we are also very very bad on planning to get things out of them again.

I remember in my first year at uni, we had a lecture on the importance, in Software Engineering, of planning for the decommissioning of a system at the same time that you were designing it. I remember thinking at the time that this seemed a bit premature: Why would you worry about getting stuff out of a system when you were just building it? Surely you’d want to build the best possible system and then people would use it forever?

I think this sort of optimism is why so many people struggle on with bad (or just plain inappropriate) systems and companies pay consultant firms silly money for “integration of existing systems”. We simply don’t plan to stop using things. And yet, we do stop using things … they become outdated, the task they were designed for changes, the job becomes less of a priority. So eventually it will be replaced by something bigger, possibly better, definitely different. And the chances are that new system will not want to just chuck everything in the old system away … the data will very likely be needed and possibly a lot of the functionality.

Commenting code, designing for reuse, object-orientation … these are all steps along the way, but none of them do what we really need to do : design for taking the system apart when it is no longer useful … and not losing everything. Keeping the original developers around forever is not feasible, nor is being trapped into whatever technology you used before “just because”. So what’s the solution? How do we best start designing for decommissioning? After all, aren’t we the best people for it? We know exactly how the system we just built works!