Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Legacy Preservation and Code Modernization

DZone's Guide to

Legacy Preservation and Code Modernization

· DevOps Zone ·
Free Resource

Planning to extract out a few microservices from your monolith? Read this free guide to learn the best practice before you get started.

The correct marketing term is "Code Modernization."

There are a large number of companies in the Code Modernization business.

They appear to offer  automated "modernization" of code.

I would suggest going slowly toward automated modernization. I'm not easily convinced that any automated tool can preserve what's meaningful and ignore the parts which are quirks, bugs or legacy cruft that needs to be disposed of.

Indeed, I'm rather sure that an automated modernization will actually be deleterious.

Without some care, cruft from the legacy code could be canonized into an incomprehensible "feature" in the modern implementation. This will eventually become it's own weird legacy quirk.

It's often best to rethink and rewrite the essential parts of the legacy. Why?


Rule One:  Writing Software is Capturing Knowledge.

Consequence:  Converting Software is Preserving Knowledge.

Knowledge is something that  people use. As with modern Agile software development, we need to focus on the connections among people. We need to use code as part of the channels of communication.

Read the Agile Manifesto:  http://agilemanifesto.org

There are four principles:


  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan


A detailed investigation into the use cases of legacy software, the unique knowledge encoded, and the quirks and cruft requires thinking about who uses the software and what they expect.

Working software (i.e., readable code) is central. An automated modernization that doesn't properly handle quirks and cruft may create "working" software in the sense that it compiles. But software that people can't read and understand doesn't "work" in the more global sense of encoding captured knowledge.

Collaboration is defeated by  automated modernization. The users may have features they don't like or additional features they need. Doing the functionality improvements side-by-side with code modernization makes the most sense. Indeed, it often leads to a proper rewrite, which is the best strategy.

It's difficult for users to envision new software that corrects long-standing quirks. When an Agile process makes software available incrementally (e.g., the release cycle of Scrum), then the users learn what they  should have requested. An automated modernization cannot easily respond to the way that users learn through each release.

Learn how to measure the impact of every feature release on performance and customer experience metrics.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}