What is Legacy Code? – Legacy Coder Podcast #5

This podcast is called “Legacy Coder” but what exactly is legacy code? I talk about my definition of the term in the fifth episode of the Legacy Coder Podcast.

Legacy Code?

• What is Legacy Code?
  • Definition by Michael Feathers: “Code without tests.”
  • Code of a certain age.
    • Brown field instead of green field.
  • “Old” languages or platforms.
    • Natural, COBOL, ABAP, Mainframes.
    • But also J2EE.
  • Code that’s hard to change or maintain.
    • You can write “new” legacy code.
    • You can also write legacy code in modern languages like Java or C#.
  • Big Balls of Mud, Monoliths.
    • Duplicated code.
    • Hard to separate into individual pieces of functionality for reuse.
    • Different concerns are bundled together (see title image).
  • Code that lacks certain quality characteristics.
    • Not readable, not modularized, not consistent, hard to understand, deeply nested, similar things are done differently, no patterns.
• How can you get rid of legacy code?
  • Why would you want to get rid of the code in the first place?
    • “Don’t forget – having legacy software is often a sign of success. Your business was successful to last long enough for your software to become legacy.” [Sam Newman]
    • High maintenance costs, aging/retiring workforce, unable to implement new requirements.
  • A big rewrite is almost never the answer. But sometimes.
  • Gradually improve the quality of your codebase.
    • Introduce tests, e.g. compare log files before/after.
  • Integrate the legacy code base into your modern architecture, e.g. with webMethods and EntireX for Adabas/Natural applications.

A short piece of Legacy Code in (pseudo) Natural

Here’s how many of the old Natural modules I encounter in my day job look like:

Database access, business logic, and the presentation of the results to the user (UI) are all bundled together into a single module. This becomes a maintenance nightmare quickly and is very hard to test because the individual concerns can’t be separated for testing.

This module could be split up into 5 different modules that only do one thing, can therefore be reused in different scenarios, and can easily be (unit) tested:

• Reading the database (e.g. subroutine READ-DATA)
• Processing the data, a.k.a. your “business logic” (e.g. subroutine PROCESS-DATA)
• Saving data to the database (e.g. subroutine SAVE-DATA)
• Showing the results to the user (e.g. subroutine DISPLAY-DATA)
• Orchestrating the individual steps to implement the whole use case (the main program)

Here’s how the refactored main program would look like:

Recommended reading (and hearing)

In his book Working Effectively with Legacy Code* Michael Feathers shows different ways of introducing automated tests into a legacy code base. He uses C++ in his examples but the underlying ideas can be applied to any other programming language, too.

*

Robert C. Martin wrote my all time favourite book for software developers: Clean Code*. If you haven’t read it already, grab a copy now and read it from front to back! No matter what programming language you’re using, you will definitely find lots of ways to improve your existing code in here.

*

In the very first episode of this podcast I talked about