Within engineering circles one of the most popular definitions of ‘Legacy’ is:
“To me, legacy code is simply code without tests.” – Michael Feathers
This might be a starting point for us when looking at legacy from a product point of view, but it is too closely tied to engineering and doesn’t allow us to talk about legacy in terms related to product development and delivery. How can we broaden this definition so that we can view it, and work on it, as a shared problem?
Legacy is that which prevents us from delivering new functionality when we need it. It prevents us from engaging with our customers, users, when we want to, and react to the market quickly enough. It is the thing that makes it difficult to provide quality at the level necessary to make our users happy. To delight our customers.
Looked at in this way, we take a step back from the view of legacy as an engineering issue and can look at it with a broader view of the system that produces legacy. After all, the situation that we are in did not come into existance out of the blue. While it can feel comforting to lay the blame at the feet of a single person, or department, there is no getting away from the impact of the whole of the system, the whole organization, in creating legacy.
Looking at legacy in these terms changes the dynamics. It is no longer something that can be seen as the sole responsibility of engineering. Or, as is often thought by the engineers, caused by the Product Owner not caring about quality. It is the result of the combination of the goals of the organization, the context in the market, the knowledge and skills, and time, available of the engineering team, as well as the way all of those work together in our organization’s structure and processes.
Legacy is all the attributes of a system, including the organization building the system, that prevents us from delivering at the pace and quality needed and expected by the market.
When we look at it in those terms, we can also clearly see that legacy can’t be solved by any independent parts of the organization. Not by engineering, not by product, not by QA, and not by decree of management. It takes a concerted effort to really improve both the product that we’re building, as well as the organization that is building it.