Technical Interest, or how Technical Debt can bankrupt your code
--
At this point, the concept of technical debt has been thoroughly disseminated among developers. Just as a refresher, technical debt is what happens when developers, usually under pressure to finish quickly, cut some corners, take some shortcuts, hack something to make it work. In other words, compress development time at the expense of code quality. But the best way to illustrate this concept is with an (all too common) example.
We have all been there: you are trying to finish a project in time. But then an urgent business need comes around. You have to create a feature in your app to satisfy that business need. The problem, though, is that the feature in question doesn’t fit quite well with the architecture you came up with. The right thing to do would be to redesign the architecture so that things fit properly and you have clean code.
Alas, when you say that to various stakeholders, said stakeholders have a conniption. There is just no time for that: promises were made, there is a competitor breathing down your neck, you need to get your app out. So, as many developers have done since time immemorial, you hack something together so that the needed feature somehow fits in the current architecture. It doesn’t look nice, QA has to spend quite some time testing to make sure things work fine, but you get the app out the door. You have your ship party and everybody is happy.
That is, until you have to deal with that piece of code again.
Of course, you thought that after shipping your app, you would have time to go back, get rid of the hack you made, redesign the architecture, implement it, and make your code look good again. In other words, get rid of your technical debt. However, it just so happens that, sooner than you imagined, your competitor came up with a new feature that’s really enticing. Those same stakeholders come to you and say that the app needs to get that new feature as soon as possible.
You tell them that you are just trying to make the code be in good shape again. And you hear back that there is simply no time for that now, you can take care of that later. Resigned, you proceed to implement the feature that was requested. Part of that new feature overlaps with the hack you had made before. Without the proper time to remake your architecture, you have to write code on top of said hack, code that in itself is not that great either. In fact, it has to go through some loops and hoops in order to make it work.
Worse still, if you had the time to get rid of the technical debt before, and put your code back in proper shape, the time to implement this new feature would be shorter. The new feature would be implemented with less effort, less chance of bugs, QA wouldn’t need to check so many different corner cases, the whole process would be more efficient. But, without that refactoring, you just accept the fact that you have to write a patch on top of a patch, and go on with that.
You get that new feature out the door. At this point, there is the temptation in the organization to say, hey, we’ve been able to ship things without spending so much time refactoring things, so clearly it is not a priority. And so your code starts to collect more and more patches, until the situation becomes truly unsustainable and your software is unmanageable.
Here is where it comes the concept of technical interest. Debt, in real life, doesn’t stay static: as time passes, it gathers interest and it grows. Likewise, technical interest describes the concept that technical debt doesn’t stay the same either: the longer it is not dealt with, the bigger it will become.
Technical interest makes it clear that technical debt is a problem that will only get worse as time passes.
Again, taking a page from real life debt, we all know that if your interest is too high, given enough time, your debt will become unmanageable and you will have to declare bankruptcy. In software development, the accumulation of technical interest will result in a larger and larger technical debt that eventually will become unmanageable as well.
To go back to our original example, that organization tried to find some time, now and then, to get rid of the hacks and bad designs that accumulated in the app. However, at that point the accumulated technical interest had made the technical debt too big, so just punctual improvements were possible. The code was composed of patches over patches that only the original developer was capable of navigating through.
But, said developer found a better opportunity elsewhere. A new developer takes over and spends long days (and nights) trying to understand the codebase, without success. So, after some heated meetings, the inevitable conclusion is reached: a comprehensive rewrite is needed, and a lot of time and resources will be devoted writing brand new code. Not only that: we are talking about new code that has to closely emulate the behavior of the previous code, which is quite a challenge in itself. So, the company has to spend much larger resources than if it had dealt with the problem earlier.
And that is the idea behind technical interest: to add the dimension of time to the problem of technical debt. It is understandable that software development companies at times have to make hard choices and perhaps not deal with their technical debt. However, by taking technical interest in account, a development organization can add the factor of time to the calculations it makes in order to determine what to work on next, what work item has the highest priority and what can be postponed.
Technical interest can expose clearly to all stakeholders that it is in their best interest to deal with technical debt sooner rather than later.
I hope that this concept can lead to wiser decisions in software development and, even better, less technical debt all around. Sometimes, the most difficult part of dealing with a problem is communicating about it, and perhaps the idea of technical interest will help better communicate the problem of technical debt and its accumulation. And, fortunately, happier coding!
