Bed Bugs and the Legacy of Legacy Code

Is legacy code a legacy term that we should leave in the past?

Why Care?

A name can convey a thousand words, but if those thousand words lead to different interpretations, confusion and distraction will occur.

The Pedantic Programmer

I can be pedantic (aka accurate, rigorous, keen to spot edge cases), and legacy code as a term leaves itself wide open for poking holes at. I don’t particularly enjoy the debate of whether some codebase should be classified as legacy or not, but when you have an itch it is hard not to scratch!

Etymology & Meaning

Legacy

Unsurprisingly, legacy is derived from Latin. Since I’m no etymology expert, I’ll leave it to you to prompt ChatGPT to give you its version of the history of the word.

Before joining the software development space, I felt pretty comfortable that I knew what the word legacy meant: something that is passed on.

legacy: something that is passed on

You can leave a legacy in your will, or create a legacy that lasts generations through the actions that you take. Even as an adjective, a relatively recent addition to our language, this definition seems to work. An outdated computer system or some other relic of history that persists into the current day can be seen as something being passed on due to inertia in how we behave or work.

Legacy Code

So what about the meaning of legacy code?

Using the above adjective definition of legacy, I would assume legacy code to simply mean outdated code that continues to be used due to some barrier to change. This barrier could be its wide-spread use, difficulty updating the code, or dependencies that prevent further change. Of course, how you define outdated code is open to debate.

I don’t think it was Michael Feathers that coined the term legacy code, but it was his definition in the book Working Effectively With Legacy Code that introduced me to it. To avoid the lack of clarity with the meaning of outdated code, Michael defined legacy code simply as code without tests.

legacy code as defined by Michael Feathers: code without tests

Debating the Meaning of Legacy Code

Of course, having a simple definition can leave plenty of room for grey areas to argue over. These are some questions that I have heard asked relating to legacy code:

• Can a codebase be considered both legacy and non-legacy depending on the part that you are looking at?
• If you are not practicing test-driven development (TDD), how long do you have after writing some code to implement the tests before your code is considered legacy?
• How many tests are enough? What level of coverage is required? Are we talking unit tests, or also integration tests, property-based tests, contract tests, etc?
• I once heard someone ( Amanda Laucher Graham ) claim that is was unethical to develop without types, so are tests even enough?
• Would you classify a simple microservice that is not tested as legacy code? What about code that is deployed to serve some purpose for only a short period of time?

The Legacy of Legacy Code

Undoubtably, the simplicity of Michael Feathers’ definition of legacy code is attractive. A codebase that is not tested is harder to change with confidence. Without data at hand, I presume that just his definition alone has had a positive impact on many a codebase, and the approaches for improving the quality of legacy codebases that are shared in Working Effectively With Legacy Code have undoubtably helped many developers.

The legacy, as a noun, that Michael’s definition of legacy code passes on includes:

• an increased spotlight on the importance of tests within software.
• accessible approaches for improving the quality of an existing codebase.
• a negative connotation for all codebases considered to be legacy.

Celebrating Legacy Code

What if we think about legacy code as a grand and old mansion? That mansion may be costly to maintain and have some outdated features. Some things may no longer work as expected, and it won’t be as efficient to run as modern alternatives. But it was crafted with skill and love, using the best tools and approaches that were available at the time. It provided enormous value for many years, and still has much to teach and inspire those that have the patience and understanding to learn.

The only reason we care about legacy code is because of the value that the code created and continues to provide. Behind the code are the people that developed and maintained it over many years. In the style of blameless retrospectives (follow Aino Vonge Corry for more on this), we should assume that the people involved did the best they could given the resources available to them at the time. Legacy code is something that we should celebrate for the value it has created, as well as being a place to continually learn from.

Beyond Legacy Code: Bed Bugs

If legacy code is something to celebrate, how should we describe codebases that are difficult to work effectively within?

I’m going to ask you to do something rather unpleasant: close your eyes and imagine you’ve just been told your bed is infested with bed bugs. Maybe some of these statements resonate with you:

• just the idea of it causes you nightmares.
• you shudder and your skin crawls.
• you don’t want to spend any time there.
• you know you’ll be caused pain.
• you are concerned about touching anything for fear of what you’ll find.
• you know it will be a huge undertaking to get the place back into order.
• you are worried about how far the problems have spread.

I could go on, but hopefully you get the point.

Now think back to the most difficult codebase that you’ve had to go in to and work with. Do you get similar feelings?

If some code causes you the same reaction as thoughts of bed bugs, then the codebase requires work!

Not all Bed Bug Code is the Same

If you live alone in a small house, maybe it won’t be so hard to get a bed bug situation under control, and you can certainly put in many precautions to limit the risk of further infestations. If you own a busy hotel or apartment block, things get more difficult. Manage public health for a large city with infestations breaking out all over? Well, I wouldn’t want that job!

A bed bug problem is never good, but like codebases that are difficult to work in, there are shades of terrible.

Working Effectively With Bed Bug Code

Staying high-level and continuing the bed bug analogy, here is a non-exhaustive list of things that we can do to help prevent and treat bed bug code:

• Effective testing. If every bed in a city was tested for bed bugs every day, it would be unlikely to ever see major infestations. However, not every test is of equal value. Implementing tests in high-risk areas — those with frequent change and interactions with 3rd party services, such as hotels and apartment buildings — should offer the greatest value.
• Psychologically safe environment. We want potential issues to be highlighted as soon as possible so as to limit the scale and the spread of problems. This can only happen in collaborative and non-blame environments.
• Minimal coupling. Bed bugs can travel along conduit and drains, as well as on furniture, clothes, and luggage. Minimizing contact points and coupling between different areas will help to isolate and minimize the scope of any issues that might arise.
• Standardized processes. Educating the public on how to identify and prevent bed bug infestations using clear and easy to follow guides and processes can help reduce risk. We can do this in our codebases with style guides, linters, architectural guidelines, etc.
• Continually learn. A city should be continually learning from the latest research, experts, and approaches taken by other cities for the control of bed bugs. Your codebase might be unique, but most of your problems will have been seen by others many times before.
• Monitoring. Increasing observability and gathering meaningful metrics will allow you to identify trends and areas of concern before they become major issues.

Final Thoughts

If a grand, old mansion has a bed bug issue, we wouldn’t want to spend time there. But after the issue has been controlled, the mansion still exists and its legacy continues.

Take care of legacy code, and eradicate the bed bugs that lurk inside!

Each week I share my thoughts on a topic that I've worked on or discussed with a client, colleague, or within the CTO community. If you've enjoyed this article then please comment or share with others, and subscribe to Tech Exec: The Week That Was to get notified when the next article drops.

If you would like to discuss CTO coaching or fractional CTO services contact jonathan@knowledge.supply.