Legacy is a dirty word.
At some point, all of us in technology will work with a system built by another team. If it’s built in way that doesn’t fit what we think is suitable, current or use the patterns that our team is accustomed to being “right” then these systems often get labelled with the word legacy.
When the word legacy is used, it often isn’t in a positive light. It’s a system that is old, broken, low quality. Often people use words like crappy. It’s the system that people don’t like to work with.
Often you will hear the teams cursing those who made these systems. They will question their decisions, without really wanting to know why or how systems got in the situation they are in, but instead to place blame.
I think this hides the beauty of these systems, their challenges, the opportunities they offer and reduces the amount of empathy people have for those who once worked on those systems.
Pre-loved Systems
In recent talks I’ve done about maintenance of pre-existing systems I’ve moved to using the phrase pre-loved. The analogy I keep going back to is how I would describe these systems on something like Gumtree or EBay.
These systems are often older or “vintage”, but not always. They often have a lot of undocumented quirks. At one time, a team put time, care and effort into building these systems. They were loved once.
Like a second-hand teddy bear, these one loved systems can be patched up, improved and loved again.
The importance of empathy
Before any code is written, any architecture planned out, any arguments about naming happens - there is always a problem identified that needs solving.
This problem is brought to a team and they spend time, effort and personally invest in building a solution in the best way they can at the time. Often it is forgotten that there are a multitude of factors that teams can face during this time.
If systems are older, one of the factors can be patterns that are acceptable or technology that are available at the time. Technology moves at such a fast pace, it doesn’t take long for something to become “legacy” or old fashioned. It takes a lot of investment in terms of time and money to keep systems up to date. Often, if they work they will be left alone, as it’s hard to justify changes. Over time, change may become easy to justify with language support, cost of architecture, security concerns or otherwise.
Other factors can be even less obvious as their root is in people. One is culture. The team may be under pressure to produce, without focus on a quality culture. It may be that during the time this product was being worked on the team had time or budget constraints.
Teams often vary in their ways of working. The code written and the way systems are designed to work are heavily influenced by the teams that work on them. In an industry where there are many ways of developing a solution, we can argue on which method is “right”, but often different teams will reach different conclusions.
Later when we work on these systems, instead of blaming these teams without knowing what pressures they faced, we should focus on how we can improve on these systems. Once these systems were invested in. It’s time to invest in them again and build upon on the foundations. We can’t change the past but we can build a future.
Challenging quirks
Working with these systems is a lot of fun, and part of that is finding their personality. When you are writing a system from scratch, you know what is planned and how it should behave. With pre-loved systems there will often be undocumented behaviours, untested scenarios and a lot of curveballs you’ll need to react to.
These quirks are fun because you can learn a lot from them. Not only the importance of things like automation, testing and documentation, but also how to work in a reactive environment.
Investing In Pre-loved Systems
At the beginning of this post I said legacy was a dirty word. Legacy brings to mind a hard to work with, badly written system. Something old, dilapidated. Something that needs fixing. An effort.
Pre-loved systems are a great thing to work with. In a previous life a team invested in them, and now they are something to be built upon. They can teach you a lot about what is important in engineering, and why. This is part of why continuous maintenance and improvement of systems is some of my favourite work.
Over time, if you build up and improve a pre-loved system, you can become invested in it yourself. It’s easy to see and measure progress. Measure the decrease in issues, the speed to deploy and more.
Love your legacy
