Software archaeology in practice

An unpleasant but nevertheless unavoidable truth of software development is that conventionally developed software ‘rots’ in time. Rot occurs slowly and insidiously, driven by the very nature of source code itself and the human factors that impinge on developing and maintaining it. It often starts when changes to source code are not reflected in documentation, leading to a loss of readily accessible information. It accelerates when development teams change and knowledge of the – now poorly documented – code is lost. It proliferates when new features are added by new software engineers, based on incomplete documentation and knowledge. It reaches its zenith as the law of diminishing returns kicks in and development progress grinds to a halt. It is at this point that reengineering the software becomes unavoidable.

From a business perspective, reengineering software is a nightmare. It involves spending a lot of time and money just to stand still. It’s also highly risky, simply because the existing legacy software is so poorly understood. And in the worst case history can repeat itself, with the newly reengineered code base being no more resistant to rot than its predecessor. This risk, and the work involved in reengineering, can be greatly diminished if the essential functionality and behaviour of the software can be recovered from the legacy code base. Future rot can be minimized by converting the legacy code into verifiably complete and correct models.