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!
Comments (2) Permalink
November 5th, 2003 at 5:01 AM
“How do we best start designing for decommisioning…We know exactly how the system we just built works!”
While it’s true that we know how the system we just built works, I’m pretty sure we don’t know how the system that we are going to decommission works. Features and subsystems will be added, and discarded over the lifetime of the system. The best we can do from where we stand at the end of a project build is to document things as best we can, and hope that someone keeps maintaining that documentation as a priority.
That said, I think you hit the nail on the head. Companies and people just don’t spend the time to plan for migrating away from and shutting down old systems. I think this is akin to the new shopping malls that keep springing up here in the USA. It’s just easier (and more fun? more profitable?) to clear away farmland and build vast shopping malls than it is to refurbish existing retail districts.
Perhaps it’s human nature that we tend to focus on blank slates rather than existing systems, even if we do more with existing systems (how much of a project is maintainence vs initial build, versus where attention is focused?).
Thanks,
Dan
November 5th, 2003 at 4:12 PM
Very good point about subsystems and amendments Dan — I admit I hadn’t really remembered that facet when I made the original post. As you say, though, if decomissioning was thought of at the design and implementation stage, then hopefully any addons would be considered in the light of the greater project … including decommissioning. It wouldn’t always work, but if there were a decommission plan, then hopefully those adding to and modifying the system would be prompted to analyse the effect on decommission of what they were doing.
I think your comment about human nature and blank slates is very insightful. At the same time, though, most of us DO spend a lot of time dealing with existing systems and their expansion, etc. What we often don’t do very well, also, is modify existing systems well (often because documentation is terrible and no-one knows how they work anyway) … which is how they end up in such a ridiculous mess in the first place.
I think there are two separate issues here … and I should probably convert them into a new post rather than ramble on and on in my own comments section 😉