Thoughts on Technical Debt

My wife and I are paying off student loans.  Obviously we didn't just take on debt because we wanted to.  Going into college, she wanted to be a teacher and I wanted to be a software engineer.  The only practical way for either of us to get the job that we wanted was for us to get the required degrees.  That meant student loans.  However, we took them on with the belief that they would be an investment that would pay for themselves in time.  And, in this case, they have already started.  Now, as quickly as we can, we're paying the loans off.  The important parts of this otherwise boring story are as follows: the only reason we took on debt was that is was unavoidable if we were to get to our goal of future jobs, and that at the first available moment we started lowering risk by paying off our debt as quickly as possible.

Boring story aside, for any kind of software project, there will be technical debt.  Whether the source of the debt is pressure to finish a project, shifting requirements, or just simply a lack of past experience to draw upon, every project will incur technical debt.  Unfortunately, without a billing statement coming at the start of each month, the nagging of engineers can be, and usually is, heard by non-engineers as "engineers just love to rewrite things that already work."  The problem is that there are severe consequences for carrying technical debt.  Most people engineers are familiar with one of them: In the future, changes take increasingly longer to make, if they can be made at all.  The other issue that many non-engineers don't seem to realize is that engineers are demoralized by large technical debt.  When technical debt increases, so does turnover.

By nature, the kind of person who becomes an engineer likes to build things, likes to improve things, and likes to generally make the world a better place.  We thrive on creation.  We spend our lives looking for ways to organize chaos.  In essence, that is who an engineer is at heart.  And those are the exact things that technical debt slows or prevents.  Continually forcing an engineer to write code that they are aware will increase technical debt violates all of the things that they have been taught, along with all of the things that they likely believe.  This is pretty much a guaranteed recipe for turnover.  The greater the frequency and degree of technical debt, the more that an engineer will feel that they're losing to chaos.

Avoiding all technical debt isn't a practical solution: as long as developers have to write things that they haven't written before, and as long as customers keep changing their minds, technical debt will continue to accrue.  The solution is to be proactive about technical debt.  Because of the risk that technical debt brings, it should be eliminated as fast as possible.  Each cycle should have time dedicated to paying down technical debt.  The obvious question this raises is "But what if I don't have time during this cycle?"  That's rarely a legimate question as much as it is a sign of completely denial, but I'll answer it none the less.  Pay down more during the next cycle.

However, a warning should be given: Following the chain of logic "I can't afford to pay down technical debt this cycle, so I'll defer" multiple times eventually leads to the thought "I can't afford to pay down debt yet, but I will eventually."  Just a reminder of something that you already know: If it isn't scheduled, it isn't anything more than wishful thinking.    There will continue being customers who wants another feature.  At some point this has to be prioritized behind fixing internal problems.  The day where a customer will say "Hey, I think you need to spend some time working on your internal APIs.  I'll pay." isn't coming.  Ever.  Just one more thing think about: if most good developers are driven off by sustained and systemic technical debt, who does that leave with you to fix your problems when you finally get ready to start paying it off?