Software Reengineering

Software reengineering is the examination and alteration of an existing system to reconstitute it in a new, improved form, typically to modernize aging legacy software while preserving its essential behavior.

Definition

Software reengineering is the process of examining a subject system to understand it and then re-implementing or restructuring it to improve its form or platform while substantially preserving its functionality.

Scope

This topic covers reverse engineering and design recovery; restructuring of code and data; migration to new platforms, languages, and architectures; wrapping and incremental modernization strategies for legacy systems; testing to preserve behavior during transformation; and the decision criteria for reengineering versus continued maintenance or replacement.

Core questions

• How is a legacy system's design recovered from its code and data?
• Which strategies migrate or restructure a system with acceptable risk?
• How is behavior preserved while the implementation is transformed?
• When does reengineering beat continued maintenance or full replacement?

Key theories

Reverse engineering and design recovery

Chikofsky and Cross defined a taxonomy distinguishing reverse engineering (recovering higher-level representations from a system) from re-documentation, restructuring, and forward engineering, framing the activities of design recovery.

Incremental legacy modernization

Rather than risky big-bang rewrites, legacy systems are modernized incrementally by introducing tests around existing code, isolating change points, and gradually restructuring or replacing components.

Clinical relevance

Reengineering lets organizations extend the life and value of business-critical legacy systems at lower risk than rewriting from scratch; sound strategy and behavior-preserving techniques are essential because legacy systems often encode irreplaceable, undocumented business knowledge.

History

As large systems built in the 1960s through 1980s aged, reverse engineering and reengineering emerged as distinct concerns in the late 1980s and 1990s, formalized by Chikofsky and Cross's taxonomy; practical techniques for taming untested legacy code were later codified by Feathers.

Debates

Incremental reengineering versus full rewrite

Whether to modernize a legacy system incrementally or rewrite it wholesale is contentious; rewrites promise a clean slate but frequently overrun and lose embedded knowledge, while incremental reengineering is safer but slower.

Key figures

• Elliot Chikofsky
• James Cross
• Michael Feathers

Seminal works

• chikofsky1990
• feathers2004
• sommerville2015

Frequently asked questions

What is the difference between refactoring and reengineering?

Refactoring makes small, behavior-preserving improvements to source code, usually as part of ongoing development; reengineering is a larger-scale activity that may recover designs and migrate a whole system to a new platform or architecture, of which refactoring can be one technique.

Why not just rewrite a legacy system from scratch?

Legacy systems often embody years of accumulated, poorly documented business rules; a from-scratch rewrite risks losing this knowledge and commonly overruns, so incremental reengineering is frequently the lower-risk path despite its slower pace.