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 …

3 Comments

  1. Avatar thomas@servergardens.com

    Rasmus Schultz

    I don’t believe the answer to technical debt is using generic third-party services or libraries – in fact, more often than not, a third-party solution to something like a contact form is going to be an enormous amount of code designed to solve every conceivable use-case for everyone.

    In my opinion, it’s not a matter of who wrote the code – every line of code adds complexity to your system. More code means more potential sources of errors, less transparency, and more misunderstandings. In the end, that’s more code to maintain – which in the long run probably means more technical debt.

    For something like a contact form, the only thing that helps with technical debt, is keeping things simple. Do not start inventing your own contact form “framework”. Do not design for reuse. And do not reuse anything – do not apply DRY, unless you actually want things to be coupled, for example because you want them to have to change together. On a contact form, you probably don’t want that, unless for some reason you’re building a dozen very similar contact forms. Do not use library code except to solve well-defined, isolated and fairly complex problems – on a contact form, you probably don’t have any of those. Write absolutely as little code as you have to. Write small units and use abstractions, so you can write unit-tests.

    If something is already easy, do not attempt to make it easier. Stop thinking in lines of code – if something requires five lines of code, but those five lines are easy to write, do not create abstractions (or pick libraries) that help you do it with two lines of code instead, because you will pay for that with accidental coupling among things that have nothing to do with each other.

    The other thing that creates technical debt, unfortunately, is our programming languages. Practically all mainstream programming languages today have poor type systems and lack guarantees. Maybe try Elm or Hegel or F# – learn about type soundness and spread the word. I’m 20-something years into my career as a software developer, and still hopeful that someday we’ll see a mainstream language that doesn’t encourage unstable software by allowing technical debt to accumulate – but sadly that day is not yet.

  2. Avatar thomas@servergardens.com

    I agree with a lot of your point, however regarding this; “In my opinion, it’s not a matter of who wrote the code – every line of code adds complexity to your system”

    If that was true the internet wouldn’t work. Simply to come here and create the comment you created, probably went through hundreds of millions of lines of code in total – Still you made it πŸ˜‰

    If what you state above is true, Google would add to your cognitive complexity and hence your employer’s technical debt. Obviously it is not. What do you think adds most to a company’s technical debt; Creating its own CMS or using WordPress? If what you state above was true, WP would add the same amount of technical debt as creating your own CMS. Obviously this is not true.

    As to keeping things simple, totally agree – As to the rest, not so much … :/

  3. Avatar thomas@servergardens.com

    Joe

    I’m finding a lot of technical debt because we used third party libraries years ago and at some point the upgrade to the next version required too much effort, time or risk at some point that we never upgraded it. We are getting bigger and bigger bills to pay to move to newer technology as the entire stack needs to be upgraded to support requirements for new library or technology we want to use.

Leave a Comment

Your email address will not be published. Required fields are marked *