As Dan quite rightly commented, another problem with decommissioning is that the system is very seldom the original system that was built. It has been modified, expanded and abused into fitting tasks it was never designed for. So welcome to “Can of Worms” Pt II … how do we work, knowing that systems will be modifed etc and still achieve elegant decommissioning?

Well, the first problem revolves around the way that we expand systems. I think that it is fair to say that systems are seldom refactored as they aught to be. We expend an awful lot of resource in terms of time, people, effort and knowledge in understanding, specifying and building a system …. and then we don’t bother to maintain what doesn’t break. Is this sensible? No. Is it understandable? Yes. By the end of it all does anyone actually know how the whole thing works? Absolutely no way.

So we need a better approach to maintenance of systems, in terms of the system itself and — the second problem — the documentation that covers it. In the corporate realm this is seldom well done and I have to admit that I have not participated in enough open source development to know if things are different though. I know that Simon has long heralded wikis and the like as possible solutions to this sort of problem. Here I would agree — a wiki to which all members of a project could contribute would be the perfect way to keep the documentation for the system alive and useful … much more so than the zipped Word or PDF files that are their usual presentation method. Ask yourself: if you changed a system, would you bother to find the latest version of the (large, complex) Word doc and update it? I know I wouldn’t and I really believe in documentation like this.

If documentation were more accessible and more useful AND included details of decommissioning plans then those modify, maintaining and looking to abuse the system would all be better dealt with. Modifications would be documented and hopefully their decommissioning considered (possibly even planned?) as well. Maintenance could become less haphazard and hopefully follow more of a refactoring approach than what one of my colleague’s refers to as the “string and cellotape” approach. And possibly, those preparing to use the system for something it isn’t designed to do will realise this and consider other alternatives. Or a bit of redesign to reimplement the system, adding the new features, possibly even changing the purpose without resulting in a horrendous mish-mash of mysterious amendments and decisions.

Could this sort of thing catch on? Would it solve some of the problems? Or would the human desire to create rather than modify, to tear things down and start again rather than build on, overcome the need to keep existing systems going onwards and upwards?