Earlier in the week I wrote a post, Why Johnny Can’t Agile. The post made a point that we might consider giving up on “saving” legacy code bases. That is, code without unit tests, with a high change failure rate, where a change in one place might break another. Perhaps it is all just too hard, and we should all give up. My arguments were strong, stirring, compelling. And wrong.
To be fair, I had data. Over the past few years I’ve worked with a dozen organizations, and interviewed or been “near to” a few dozen more. Many of them do big public presentations about their agile adoptions. When I visit, they invariably have sprints, stories, and standups. The work may be sliced thinly – perhaps too thinly. I see stories like “a new etr to the table” that could be written as “create a single INSERT statement in a database that is essentially a cut and paste.” Everything seems to take a long time. There is not much joy. The magical feedback and improvement loops that inspired the title of Jeff Sutherland’s book Twice The Work In Half The Time — those simply do not happen. In my previous piece, I called a real agile adoption “next to impossible.” This was my working hypothesis:
I’m starting to wonder if we should say “legacy systems should be managed differently than greenfield development. Count the cost. You may come to different conclusions.”
It was Lisa Crispin, one of my peer reviews, that pushed back strongly on this. After all, she had been on companies that had broken through (as had I), more than a few times. If I wanted to give up on saving legacy projects and teams (which is most of them), why the sudden change of heart?
Explaining the Crispin Confusion
First of all, let me be clear. A few teams do make the jump. Lisa is known in our world for being an employee – albeit one that writes and speaks a great deal. I would hope that if a company was aware enough to realize who she is, then goes through the effort court her and pays a reasonable high enough pay band to get and keep her, their chances of success would greatly improve. I am not saying Lisa does the transformation herself (though I would expect she would help), but instead the kind of company that would hire her is likely the kind that could make a change stick.
And it is possible to get out of a code debt mess. You start by isolating external systems. So, for example, your database, disk, and network connections come from a class. Instead of creating that class at runtime, you pass it in. That allows you to cut out the dependency and pass in a stub or mock for testing. This allows you to write unit tests without needed the universe of external dependencies. Then, you can improve (refactor) the pieces you touch as you touch them.
Another common strategy is the strangler pattern. This is replacing an older technology with a new one bit-by-bit, keeping the told tech running until there is nothing left.
In her comments on my review, Lisa wrote:
I think this is a perception thing and it’s hard to fight. It’s not really any more difficult to rescue legacy code than it is to master TDD on greenfield projects. It just IS hard and so people think “Oh if it were greenfield I could do it, but it’s legacy so I can’t”.
I know the patterns. So why did I give up?
Getting work done
Some companies are just not structured to get work done. For example, management might split the teams by type of work. Getting anything done means the driver has to ask someone else to do something – and the service level agreement says three days for a one hour task. Then then need to ask someone else. Eventually, it takes a month to perform a six-hour task.
If you’ve been in an organization that wasn’t really structured to get work done, you know how easy it is to delay and defer. I’ll write that email tomorrow, we’ll schedule that meeting for next week, I’ve passed that dependency to the Scrum master so I can go work on something else. There is a sort of negative inertia that pulls everything down. Your work is not urgent to anyone else and you are dependent on them. Getting anything to change is a challenge, and a real agile adoption requires so many things to change. Meanwhile, the benefits of a more agile way of working won’t show to management for weeks or months. All anyone knows is that, right now, the new approach (TDD, smaller stories, acceptance criteria, pairing) would mean more work — so we can put that off until tomorrow. Sometimes, tomorrow never comes.
Starting a team moving forward with a legacy codebase is a bit like starting a boat. It takes a lot of energy to get the boat moving. Keeping the boat moving forward – maintaining that inertia – is a lot easier. Starting a new codebase is a bit like starting up an empty boat. Compare that the effort to get a boat moving that is full of cargo, and you see how striking the effort difference might be. Now try that in an organization not set up to get work done. Add in people afraid of the loss of their position, and you become amazed Agile adoptions ever have real lasting success.
Going back to that original quote, i’m not so convinced I was totally wrong. The claim was that legacy systems need to be approached differently than new development. With new development, you can start the project off on the right foot. With legacy software, the question is what tweaks to start when. Historically, the failure rate at that approach is high. Ken Schwaber once said his estimate was the 75% of organizations trying Scrum fail to see the results they had hoped. That is 75%, which is not one hundred percent. “Failed to see the results they had hoped” and “failed to see any results” are different.
Over the next few weeks and months, I’ll sharing the problems and solutions I have seen in this area. We’ll explore the strangler pattern in practice.
Today’s problem is inertia.