Writing Tomorrow's Legacy Code Today
As I reflect on Thursday’s work, and chat with Chet about it, I am beginning to feel that we have an interesting “Technical Debt” situation. As a principle, I hold that we should keep our code as close as possible to having zero debt, that is, zero difference between what we understand about the program and solution, and what’s in the code.
If we have an idea about how the code should be, it should be in the code. Or, as Beck’s Rules of Simple Design put it: The code expresses all our ideas about the code.
As we worked yesterday, I felt a few times that we should just revert the code and begin again. We pressed forward instead. Reviewing the code this morning, I felt that we “should have” reverted. I think the result would be better if we had.
But our tests are green, and we are at an improved state, and we know pretty exactly what we’ll do next about removing the duplication from our file moving code. We’ll talk, next Tuesday, about reverting and doing it over. We’ll nod at each other and agree that if we do, it won’t take the whole morning, and the result will be better.
And then we’ll decide to press forward. We’re at a green bar, we know what we need to do, no need to revert. We’ll fix any issues with the code as we go along.
Legacy Code
My advice with legacy code is always to improve it as we work on it, not to try to rewrite it. That’s what I’m sure we’ll decide to do.
My God! Yesterday we wrote Legacy Code!
We could throw it away and write something better. But I never recommend rewriting legacy code, I recommend improving as you go. Now when I make that recommendation, I’m talking about a rewrite of a larger system or a lot of code, not a few hours’ work. So maybe the principle doesn’t apply.
But it probably does.
So that means that on Tuesday, Tozier and I are going to make a “rational” decision to accept some technical debt.
Now that’s not at all the same as if we had said, yesterday, “Let’s write some technical debt today”. We didn’t decide, rationally, to create and accept technical debt. Instead, we’re about to decide between stopping progress to remove the debt, or removing the debt incrementally.
I think this is the rational decision, now. And we didn’t consciously decide to write legacy code yesterday.
But we did write legacy code yesterday. There’s no way around it. And now we have technical debt. There’s no way around it.