Every developer at some point in their career has encountered “Legacy Code” – and the phrase usually implies negative connotations. There are usually reasons for this – Legacy Code is normally code that is hard to maintain, perhaps code that has grown organically over time and become complex, using technologies that now are out of date. There’s another way to look at this though.
A couple of years ago I was working with an all-contractor team, who had been tasked with modernizing a piece of software. This team were particularly critical of the old systems, and the way they had been built – and it annoyed me to be honest. What this team had failed to recognize was that whatever the shortcomings of the old product were, it was paying their wages! The product had grown over a period of time, more according to customer requests than to any plan. This produced a codebase that wasn’t the cleanest, but customers loved the product. The codebase had earned the company enough money to pay for a new version to be written, and kept the company profitable for a long time. Perhaps in this situation a better name is “Breadwinner Code”?
When we work with “Legacy Code”, we should remember the journey it’s been on. We should assume that every decision, every action, was with the best intentions, in the best way, with the knowledge, skills and technologies available at the time. We live in an era where there are countless startups who burn their way through piles of investor funds without ever releasing a product or earning any money – so when we come across a product that has earned its stripes with real customers, we should show respect where its due.