My focus in an engineering org is to increase the quality and health of the codebase. Nobody wants to work in a code base infested by monolithic legacy files. In my time working with enterprise services I have experienced many different stages of code health. At their biggest, companies suffer from code rot severe enough to drive engineers out of their jobs. Code rot can be caused by multiple factors, but more often than not it is an effect of technical debt.
The first question I get from management is, what is technical debt? Do you mean bugs?
Ok… do you mean an unfinished feature?
Is it what made the government shut down?
No.. wait, what?
To be honest, there are as many definitions of technical debt as there are engineers in the world. I’ll present a few from the more prolific coders.
From Martin Fowler:
To summarize, it is a debt that you incur everytime you avoid doing the right thing (like refactoring, removing duplication/redundancy) letting the code quality deteriorate over time. As with financial debt, it is the easy thing to do in the short term.. however over time, the interest you pay on this debt is humongous – the code quality deteriorates over time to a point where a rewrite of the app is more feasible than maintaining or changing it. (So the question is whether you want to pay a little now (fixing the tiny issues) or pay lots more after N months (by which time the code has turned into Jurassic Park II).
From Robert C. Martin:
…the engineering trade-off’s that software developers and business stakeholders must often make in order to meet schedules and customer expectations. In short, you may need to use suboptimal designs in the short term, because the schedule does not allow longer term designs to be used.
And from the alleged inventor of the term, Ward Cunningham:
Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
So you can think of technical debt as a response to business pressures, or you can think of technical debt as a sign of lazy coders. But whatever you label it as, technical debt has the ability to cripple a company.
How do I find my debt?
Often times the engineer dealing with technical debt isn’t the one who created it. If they were, they would know where it is. That being said, there are two ways to find technical debt: look for it, or wait until it smacks you in the face.
Looking for technical debt begins with getting to know the code base and those who work on it. When I started on the Platform API team at Box, I had 1:1s with every engineer, and I asked them what their pain points were. I found out what areas of code were untested, what areas were due for refactoring, and what areas were suffering from being tightly coupled with other components.
If you don’t find technical debt, don’t worry. It’ll make sure you know it’s there. It will probably wait until 4am on a Wednesday when all of your users are locked out of their accounts, or while onboarding a new client your friendly technical debt will say “Hello!” with a constant stream of 500 error codes.
That being said, another logical place to look for technical debt is in the past. Seeing as how your team has been disciplined in its use of bug tracking and postmortem reporting, you should have plenty of data to look through. Root cause, ask the five why’s, and find where in the code the issues originated, and what about your processes prevented you from detecting it early on. This is the difference between putting a band-aid on a problem, and cauterizing the wound.
That’s nice and all but I don’t really have time for that
Of course, business needs are important. Without a finished product, there’s no way to keep the kool-aid kegerator in the break room on. Finding a way to integrate the cataloguing and eventual fixing of technical debt is more of an art than a science. Just remember that technical debt is a loan, and it gets worse with time. The worst feeling is when you realize that a project came in two months after the deadline because nobody was picking up the proverbial “garbage on the ground”.
If you can successfully balance your technical debt, the long term effects will be very fortunate for your engineering org. And you can brag that unlike the federal government, you were able to keep the lights on in the office.