by Leon Rosenshein

More Than Cruft

I’ve talked about Tech Debt before. The idea that, like with earnings, you can trade future work and understanding for earlier delivery of a product, then pay it back later. It made sense when I first heard about it, and it makes sense now.

What’s important though, is to do both parts. Not just pushing work or learning into the future to speed up delivery. But what does that really mean? It means being an owner and thinking not just of delivery dates, but of future developers, which includes you. You’re not just making life harder for some faceless future person, you’re making life harder for yourself. So it’s in your own best interest to do it knowingly.

It means doing things with the best information and understanding you have at the time, then, as you learn, do the important things, the critical things, that you put off. Making sure the code reflects your current understanding, at all times. You made the choice and bought the time. Maybe it was for a demo or a holiday ship date, but you made the choice. Now live up to the promise you made to yourself and your customers. Take the thing you got by releasing sooner, the capital (feedback, experience, brand recognition, investment, whatever) and put it to use. Update the user interface after watching your customers use it. Refactor your domains now that you know what they really are. Add error handling and the operational domain outside the narrow happy path you just implemented.

While I’ve known Ward Cunningham came up with the idea and I recently came across this description of the situation where he first started using the term. At the time he was using Smalltalk and talking about objects and hierarchies. We don’t use Smalltalk, and where he talks about objects he’s talking about domains and domain driven design, not objects as defined by a particular language. And doing things that way, keeping your domains clear and bounded, is what keeps your debt from burying you. It’s what allows you to keep the promise you made to yourself when you took on the debt in the first place. It’s about keeping things clean enough so that you can be agile enough to use the learnings you took on the debt for in the first place.

And if that isn’t clear enough, here’s Ward himself talking about it and a transcript if you prefer.