Jonathan Starr in a recent post, asked his readers:

“As we software engineers refactor someone else’s code […] at what point is the new application essentially not the same as the legacy application that you improved?”

Software rarely occurs in isolation, especially enterprise software. Often years of business rules, legacy systems, and even unjustified rational guide and shape the applications we work on.

When you are involved in a massive re-engineering of an existing application, you typically work you way piece-wise through the code. It is in this fashion that you systematically rework entire subsystems of the application. During this process we are hardly aware that, despite our best intentions, we are not truly guiding the design of the application. The legacy design is guiding its own redesign.

We often have to shape our ideas to fit into the legacy mold the application presents. This, coupled with the same business needs and environment that shaped the application originally, is precisely why most applications never truly change. The source code may look different, however the differences is purely cosmetic. Much the same as how an adult is still the same person as they were as a child. The adult has a few new behaviors, some they don’t perform any more. The adult even looks, walks, and sounds different. But the adult is still the same person they were as a child.

An application can only truly be reborn, when it is clean room re-engineered, as anything short of this would re-introduce the “spirit” of its predecessor.