http://www.cwi.nl/˜{arie,kuipers,leon}/ {arie,kuipers,leon}@cwi.nl Software Renovation 1. I NTRODUCTION One of the key elements of extreme programming (XP) is design for today, so that the system is equally prepared to go any direction tomorrow. As Beck argues, XP gets away with this minimalist approach because it exploits the advances in software engineering technology, such as relational databases, modular programming, and information hiding, which all help to reduce the cost of changing software [Bec99]. The result of this is that the software developer does not need to worry about future changes: the change-cost curve is no longer exponential, but linear. Making changes easily is further supported by XP in various ways: Releases are small and frequent, keeping changes small as well; The code gets refactored every release, keeping it small and adaptable; Testing is at the heart of XP, ensuring that refactored code behaves as it should. The assumption that the system under construction is easily modifiable rules out an overwhelming amount of existing software: the so-called legacy systems, which by definition resist change [BS95]. Such systems are written using technology such as Cobol, IMS or PL/I, which does not permit easy modification. (As an example, we have encountered a 130,000 lines of code Cobol system containing 13,000 go-to statements.) Moreover, their internal structure has degraded after repeated maintenance, resulting in systems consisting of duplicated (but slightly modified) code, dead code, support for obsolete features, and so on. The extreme solution that comes to mind is to throw such systems away — unfortunately, it takes time to construct the new system, during which the legacy system will have to be maintained and modified. Now what if an extreme programmer were to maintain such a legacy system? (Which means he was either forced to do so or seduced by an extreme salary). Would he drop all XP practices because the legacy system