Lowering the impact of technical debt by pretending your code is better than it is
Technical debt can be a major concern for software companies. I’m not going to go into all the reasons why it seemed like a good idea at the time, but it inevitably happens and then you get stuck with all sorts of weird, quircky, or downright ugly pieces of code.
And later on, you will need time to fix them again. Which starts with trying to find them. That can often be a complicated task in itself. Next, you’ll have to start building a better solution. Finally, you need to start replacing all the places where the debt is with the new code. And they can be hard to find, because they often aren’t labeled clearly. (If you take anything from this article, let it be that you should always leave a marker-comment above anything you know is going to be technical debt.)
Imagine the simple (but common) example of user rights. If you build a new, simple system prototype you probably do not want it to come with a complicated user rights management system. Just show everything to everyone and get your prototype working fast.
Then the first steps into a rights system appear. A few checks here; a few checks there. At some point, you realise you want to start using an actual rights management system. So you start implementing one, and then you start looking for all the places where there was a check. Hopefully you can find all of them.
A lot of work. But there might be a way to prevent a lot of that work by changing the way we deal with technical debt and these important, but not right now features that always crop up in software development.
So I’ll introduce what I call an imaginary system. When you think about the kind of things that encompass technical debt, the general idea is that there is a feature that would be useful for the program to have, is important for the future maintability to build well, but would take time to create that simply isn’t available.
Going back to the user rights example; it’s not that building a rights management system is really complicated, or requires a super complex architecture or hours of meetings to think about how it should look. It’s simply that building one would take a lot of time you don’t have. So instead of building one, you add a simple if to your code somewhere and call it a day.
But since thinking up the architecture isn’t the real problem and you can probably come up with a basic interface for it in a few minutes, why not simply pretend the system is there? Anything hidden behind an interface isn’t messing up your code. Why not write something that looks like a legitimate, well engineered solution in the place where you’d otherwise incur debt?
The above code accomplishes the same thing as the first, except it looks like a genuine user rights system. However, since we don’t have time to actually build one (we were busy incurring technical debt, after all) we can simply implement this function in 3 lines:
Now we’ve spent a few seconds writing a few extra lines, but the payoff is going to be huge. We can keep referencing this function in other files, classes, views, templates, anywhere. It’ll work just fine without ever really implementing it as long as we don’t have an actual rights system.
But the moment we decide to get rid of technical debt by actually implementing a user rights system, there is no need to search for all the places in the code where we’ve used a quick check instead of a good solution. No matter how often a quick check has been added, no matter how often there was no time to do it right, no matter how many permissions and exceptions have been added… we only need to change 1 thing. We need to take out the imaginary userpermission system and replace it with a real one.
By pretending we’ve been talking to a proper system all along, all we have to do is actually build that proper system and install it behind the interface. Since any code talking to an interface doesn’t (well, shouldn’t) care what is behind an interface, replacing the fake for the genuine is a painless switch.
Much better than adding actual clutter to your files. Technical debt doesn’t mean there aren’t a few minutes to think about proper design; it means there aren’t enough hours to build that design. But you can always fake it until you make it.