Technical debt is when a company has poorly written legacy code that they are afraid to change, due to fear of breaking existing systems. According to research in the topic, 59% of business leaders in Norway said technical debt was their primary obstacle preventing them from innovating. When you have a lot of technical debt, it feels like you’re trying to steer a boat, with the anchor still attached to the bottom of the sea.
The origins of technical debt and the mechanisms that creates it are actually quite easily understood. It happens as a consequence of “a small rapid fix” in your systems, adding another if statement to an already complex function, until your software has become so complex, nobody dares to change it anymore, due to fear of breaking other parts of the system unintentionally. Software developers refers to such systems as “Big balls of mud” or “Spaghetti systems”. Paradoxically we have known how to avoid technical debt for decades – However, “nobody” follows this recipe, because, and I quote; “They don’t have the time”. So hacks are applied to existing systems, until they become so unbearably complex, all future innovation is stifled, and everybody suffers. Accumulating technical debt, and the process that creates it, is the equivalent of building your house on a foundation of mud.
Why is it important?
A company might want to change its business processes at some point in the future. For instance, your marketing department might have found great potential related to changing the ordering of fields in some registration form onboarding new clients, and marketing might want to change the ordering of these fields. If your system is a big ball of mud, such simple changes are often impossible. This is because your business processes are implemented in software, and if you can’t change your software, you can’t change your business processes. This results in that instead of your business department telling your software department what they should do, the software department typically tells your business department that what they want to do is impossible. In fact, you can quantify your amount of technical debt by measuring how often your software department tells you; “It’s impossible”, and you probably should do so too may I add.
“Wag the dog” comes to mind … :/
What’s the fix?
Encapsulation is the key to avoid technical debt. Encapsulation is “the art of hiding complexity”. For instance, when I start my car, there are probably 500 moving parts involved in the process. However, I don’t need to think about these parts – All I need to remember is to turn my key in the right direction, and the car will automagically start after a while. If we could create our software the same way we construct cars, we’d avoid technical debt. Of course, if you ask most developers, they will claim they are indeed applying encapsulation – Regardless of how complex and muddy their systems are. Hence, somebody here is obviously not telling the truth …
I don’t mean to blame your developers. Most developers are nice guys and gals, trying their best to please their managers – And often technical debt is accumulated due to “just another change here please”, without thinking about the long term consequences. However, there is something fundamentally wrong with the way we create software …
Let me repeat that again in case you didn’t get it …
THERE IS SOMETHING FUNDAMENTALLY WRONG WITH THE WAY WE CREATE SOFTWARE!
Got it …?
If you ask the average developer to create a registration form for your marketing department to onboard clients, he or she will happily start churning out code, waiting for that familiar pat on the back telling the developer; “Nice work!”
Instead the developer should ask himself; Did anybody else solve this before me? At which point the developer would probably find some micro service module having solved the problem, applying years worth of cognitive energy into the problem, resulting in a super flexible registration form, the developer could bend to his marketing department’s will in the future. However, the software developer doesn’t have any incentives in this process, because it’s “less interesting work” – And from the individual developer’s perspective, the more he or she gets to actually code, the more he or she learns. The more the developer learns, the more valuable the developer will become in the future. In a way you might argue that the way the art of software development is rigged results in individual developers having personal incentives in SABOTAGING THEIR EMPLOYER!
Yet again, this is not the individual developer’s fault, it’s systemic. The system is rigged, and it’s rigged in such a way that the more muddy code the individual developer delivers, the more successful it becomes from an individual point of view.
Facts are, we need to stop rewarding developers according to how much they produce, and rather start rewarding them for everything the DO NOT produce! Simply because every time a software developer produces something, he or she accumulates technical debt on behalf of his employer, resulting in that innovating in the long term ipso facto becomes impossible.
Instead of rewarding the developer for the clever thing he or she created themselves, we need to start rewarding the developer for every thing he or she did NOT create – But rather found a beautiful pre-existing micro service module that solves out of the box, without the developer having to apply as much as a single line of code to make it run
Of course, this way of running a software development department is incredibly difficult, because it feels as if you’re paying the developer to “do nothing”. But actually, finding a beautifully architected pre-existing micro service, is probably orders of magnitudes harder than implementing a poorly written big ball of mud from scratch. I have said this before on several occasions, but a good thing cannot be repeated enough, and it’s target audience are developers suffering from the “not invented here syndrome” …
Your job is NOT to create software, it is to THINK!
Simply put because every single line of code you add to your employer’s git repository, becomes one additional grain of sand, adding to your employer’s amount of technical debt, one line of code at the time …