I love legacy code!

I’m not joking and I’m not crazy, that I’m certain. Or, at least, I believe so. Let me explain.

Have you ever stared at the screen thinking about which programming language, database, framework, tools, etc, you want to use for a greenfield project? It’s like the blank-page syndrome tormenting writers but for programmers. This might not be a big problem when given the project constraints. However, when given a free pass to do whatever you want in, let’s say, a web API, the sky is the limit, and too many choices can be paralyzing. In The Paradox of Choice, Barry Schwartz argues that the more options we have, the more it overwhelms us.

After reflecting on that, constraints can be liberating. Taking this logic to our legacy code, we don’t need to reinvent the wheel, everything is already there and we only need to tweak some things here and there and leave the campground cleaner than we found it. We can move forward by taking baby steps and a sane person will avoid at all cost to do big leaps when dealing with legacy code — when in doubt, don’t!

No tests? Fine, start writing the smallest test that will make you move the first needle from the haystack. Whatever makes you move forward.

Minimally covered? Now do the minimal change possible.

Repeat ad infinitum (until good enough).

This tends to be my modus operandi. Yours might be different, whatever. You got the idea. No analysis paralysis!

I know, I know. There are numerous technical challenges, such as managing dependencies, deployments, ownership, no documentation, etc., that can get in the way of a pleasant development experience. I know because I used to be the guy complaining in such situations. However, looking at it from a different perspective, we can start taking ownership of little pieces and pitch improvement ideas rather than maintaining the status quo.

Decisions were made in the past, people might have gotten burned and moved on, and the programmer developing the software most probably did his/her best at the time. Assume good intentions.

We can argue that working on legacy code takes your time and energy away from more impactful projects, that nobody cares about legacy, and that this kind of work doesn’t count toward promotion, and that may be right. But this is a different problem living outside the technical realm (already in the political zone), and I’d prefer to discuss that in the bar, after some beers. 😉

Thanks for reading Bit Maybe Wise!

You can also follow me on Twitter, Mastodon, and BlueSky.