As part of improving our understanding of a legacy system, in “The Product Owner’s Guide To Escaping Legacy” I explain how we can go about discovering new information about a system, and how we can keep track of how we are currently testing that functionality. Then, we use that knowledge to be more targeted in our approach to testing. The goal of testing is to be able to release with confidence.
As I was giving another version of my Discovery and Formulation training recently, I noticed again that one of the ways I use the story map as a basis for planning is quite unfamiliar to people, and I actually think that it is one of the simplest ways to help teams to actually start delivering in small iterations. So, I figure I’d write a short description of it here.
The term Technical Debt has been wildly successful. Ever since it was first introduced by Ward Cunningham in 1992 (Ward Cunningham, “The WyCash Portfolio Management System”) Technical Debt has grabbed the collective consciousness of the software development community and has functioned as a label applied to all the different kinds of technical shortcomings we can imagine. The first version of Technical Debt is the one originally described: taking a conscious decision to postpone a change in the structure of our system, the need for which was triggered by new functionality, to facilitate a faster time to market.
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?
So many of us end up in the same place: with an application that we’ve built, as quickly as possible, that has found enough users, and that seems to be getting harder and harder to do any changes to. We describe the state we end up in using terms like legacy system, technical debt, long manual regression cycles, or less polite terms. Working with a variety of companies that have come to be in that position, I’ve found an approach to dealing with these situations.
I recently decided I want to get better at playing the piano. 30+ years ago, I had some lessons playing the electronic organ, but though I’ve played a few things since on a piano I’ve never taken it seriously enough to do some deliberate practice. That means I’ve played a few songs from sheet music, but haltingly and never practiced enough to get the difficult parts right and the whole song memorised.