Make technical debt a deliberate choice
Technical debt — one of the most polarizing topics in any software development team
In my experience we tend to approach technical debt in one of two extremes — #1 “ain’t nobody got time for that!” or #2 “we need to rewrite this from scratch and then all our current problems will be gone”.
It appears to be an “all or nothing” game. As in most things in life the truth is probably somewhere in the middle. For now, let’s look into each of those two approaches a bit more closely:
#1 “Ain’t nobody got time for that!”
All too often, when dealing with software, there is pressure to release that new feature, to enable the customer to do one more cool thing, that next amazing marketing campaign is about to launch … “we just need to get it done as fast as possible”. When this is the case, technical debt tends to not be part of the discussion and gets bigger and bigger. No one ever asks anyone to create technical debt, it’s just there, a byproduct of running too fast to get things done before that next deadline. And it’s tempting to keep working in this mode, after all, we’re getting a lot of things done fast, right?
Well, yes, for a while, until “suddenly” everything starts taking longer and longer … until someone says:
#2 “We need [insert long amount of time here] to rewrite this from scratch and then all our current problems will be gone!”
It usually takes some convincing and quite a few broken deadlines on the account of technical debt, and then, finally, the development team gets what they’ve been waiting for for such a long time — the go-ahead to rewrite everything. In that moment the spirit is high, motivation is through the roof, diagrams, conventions, agreements and most importantly pledges of “we’re never doing that mistake of the old system again”. And slowly but surely, usually in twice the time you expected, the system is rewritten. Finally adding new features is supper easy again, and you can go back to square #1.
I’m sure many of you have been there, I know I was. But what if there’s another way of “using” technical debt. You could think of it as a business loan you get from a bank. You take a loan, so that you can build faster than what your current resources allow you. Once done, your revenue flow is (hopefully) improved, and you can use these gains to pay off the debt you took on, while you keep collecting the rewards. And like any bank would require you to do — there comes a time to repay that debt, either as a whole big sum (#2) or as more manageable regular installments (#3).
Having done both of these approaches in the past (#1 and #2), I can tell you that neither is a really sustainable solution.
#3 Make technical debt a deliberate choice
I strongly believe that we need to get much more familiar with technical debt, we need to take a close look at it, accept that it’s simply part of the game and that the ignore or rewrite everything approach is not really an efficient way of dealing with it. Instead, there are ways of dealing with technical debt as we go along, so that we keep the technical debt paid off in small installments AND we get to build new valuable features.
Once you get to being really comfortable with the idea of seeing technical debt as a deliberate way of getting business insights faster, you can use it to evaluate faster which ideas work best with customers. Armed with the knowledge you can then clean up after yourself where it makes sense and delete the whole thing where you learned that your idea does not work with customers at all.
Technical debt should only be added as a deliberate choice. Do anything in your power to avoid any other kind.
I’ll be writing a follow-up with very concrete ideas how to approach technical debt together with your team/organization, so do come back.