The term ‘legacy code’ is often used to frame our thoughts. If one talks about that we already are thinking about pain-points, old dusty code that is hard to understand. I think that‘s a wrong way of thinking: you are in the current spot to fix/renew that code because it proofed itself to be working and is worth upgrading for one or another reason.
I want you to reframe that mental model from a dusty window-less cellar to a playground swing in which a hedge and a tree a blocking you to use the swing. You can see it through tiny holes but can‘t quite touch it.
You are not a software developer any longer
If you are in a place to refactor that code consider yourself not as a software developer, you are a software archeologist.
- An archeologist needs to find a good place to start digging. The knowledge where or how to start is your experience. No archeologist just started in the desert somewhere, they had clues.
- After some digging they may find something and need to carefully get hold of the thing to uncover it. Which can be hard work. Imaging finding some dinosaur bones inside stone. It has its challenges to free and uncover it.
- Before you remove the thing from it‘s original place it needs to be documented in a map with images.
- The extraction maybe the easiest part compared to find a meaning, discover its usage or make sense of it. Has it been left on purpose or was it there by accident. Always considering the place it has been found. Daily use items, like a coffee mug, or a special ritual celebratory mug.
I think this all compares well with the work of a software developer tasked with maintaining or refactoring an old code base. We must match our expactations to match the suroundings and just go with it. It is not worth yelling at the old codebase, it will not change nor will it tell you its secret.
It is up to us to discover the meaning and present it to our colleagues to share knowledge and maybe even find the usage for that code.
Grab your hat, bull whip and start the day as a famous archeologist.