Mindset for Working With Legacy Code

This resource first appeared in issue #12 on 28 Feb 2020 and has tags Technical Leadership: Software Development, Technical Leadership: Migration

The key points of “Working Effectively with Legacy Code” - Nicholas Carlo
Exit the Haunted Forest - John Millikan

An awful lot of of code we work with in research computing can be thought of as legacy code - whether it’s functioning but old code that to meet current needs needs to be refactored, or whether it’s new code from a researcher which just isn’t maintainable in its current form. I like to think of reworking such code as helping the code reach its potential.

Working Effectively with Legacy Code by Michael Feathers is a hugely influential book on that topic, and is comfortably in the top half of a list of top-twenty-five most recommended programming books on the web that was published this week. The book has been influential enough that even those of us who haven’t read the book are likely aware of its basic tenants, like “Legacy code is code without tests.” Nicholas Carlo, who has a newsletter on working with legacy code, walks us through a nice summary of the book and its five basic steps:

  1. Identify change points (Seams)
  2. Break dependencies
  3. Write the tests
  4. Make your changes
  5. Refactor

The post by John Millikan focusses more on step four, making changes. Code that has become legacy through age usually got that way because it was resistant to change - after developers had tried to make inroads into the haunted forest to be chased away by bad experiences, others started staying clear. While it’s true that good code is all the same while bad code is each bad in its own way, there are some common patterns of the sort of badness that have resided being changed, and the post describes how to wrestle with a few of them.

<<<<<<< HEAD
======= >>>>>>> c1d069a... First pass at category pages