Tech Debt First

Everybody is familiar with the concept of technical debt. Some people might refer to it using different metaphors, Fowler calls it cruft, Allan Kelly call it a liability. I personally prefer Kelly’s definition. No matter what metaphor we use, technical debt is a reality in all industries. Technical debt is everywhere.

Not all technical debt is created equal. Some problems are worse than others; for instance, if we have 6 lines of duplicate ifs inside a single method or function, it’s not as bad as a distributed monolith. Have you ever tought about what’s the norm? Do you think technical debt is the exception, the anomaly? Or do you think technical debt is the norm and happens by default? We will go back to this question later. I believe it’s impossible to avoid technical debt. IF you think about it, let’s say you have the perfect team and the talent. It’s amazing; all your team members have 20+ of experience, in the same industry and have been working together for 10 years. No matter how good your talent is and how long-lived the team is. Mistakes will happen. Some mistakes are silent and will only manifest years later; not all tech debt is evident and clear. Lots of tech debt. It’s pretty clear and obvious, but it is really up to the eye of the beholder. We can’t wait to have the perfect code, which easily would lead us to paralysis and not getting things done. It’s not the right to go, either. However, what is the norm?

Normalization

Unfortunately, I think in all industries, technical debt become the norm. It happens by default. No matter the organization, it’s easy to guess that they will be using Scrum and React for the front end and Java for the back end because these are the current norms. To the same degree, technical debt is the norm. I’m not saying it’s a good norm, or I agree with the status quote of the industry, but it is what it is. It’s important to acknowledge the problem; otherwise, there is no way we can fix it.

For instance, 20 years ago, it was normal to build websites as the default solution. 30 years ago, it was normal to build desktop applications; today, the norm is to build mobile applications. Often, solutions have multiple interfaces, and it is very common to have mobile, web, and sometimes even other interfaces like voice, VR, or even chat, in the case of LLMs. So far it’s common and often call it: mobile-first. You build the mobile application first, which makes sense.

Today, we live in a world of technical debt. Which technical debt is a preemptive choice? To some degree, I think we went too far. Yes, sometimes you are learning and will make bad decisions, which will lead to bad code and, therefore, technical debt. But are we making any effort to avoid technical debt at all?

The problem with normalization is that if everybody does it, we use this as justification. The right is right even if no one does it; the wrong is wrong no matter if everybody does it.

Now, let’s stop talking about software for a moment and consider a different field and industry, such as space exploration and telecommunications.

Space Debris

You might think that technical-debt first is a technology problem; as humans, we are always organized, and this is a unique technology problem. Well, it’s not. You might think that Earth, the planet where we live, looks like this (Earth by Wikipedia)

IF you said “yes” “ it’s a pretty good and reasonable answer. But that is not accurate, at least not anymore. Maybe it would be correct if we asked such a question in the 50s. The reality is that there is a lot of space debris around Earth that no one cleans up. Some of this debris got pulled by the earth’s gravitational field, and it burns, but a lot of the debris keeps spinning around us. (second take on Earth by MIT)

Current view of Earth from space (do you see any debris?)

So what can we do? What’s going on is that some people are trying to create a rating system to rate the sustainability of some products that go to space as a way to reduce this problem. Now, what is going on here is the following:

• The problem keeps growing; it’s not getting better
• Clearly this is the norm, it’s normal, this is normalized and “acceptable behavior”.
• There is a risk of collision

I’ was not talking about software(earth space debris problem), but this applies to software. I dont think we need a rating system, but we need to change something.

More time and more money?

Often, we think the solutions lie in more. More money, more time, more time. I dont think thats the solution. IF we have more people, we will produce more technical debt faster. What needs to happen is the following:

• We need to stop normalising technical debt like there are no consequences.
• We need to move from technical debt first, to technical debt as the last measure.
• In order to change, we need to start seeing things differently; pressure will never go away
• It’s possible that we behave differently and find better ways of working.

Many people think they can only fix a problem if they have time and a specific project to work on. Yes, time, money, and people always help, don’t get me wrong. But hey, you are in a team, your company already has money, and you do have time. So why dont you behave differently?

Here are some tips and advice on how to close this gap and start doing things differently:

• Push back: Sometimes, when things are “too much,” we need to push back. Consider adding one more day to your task to do some refactorings.
• Refactoring Know-How: Do you know refactoring techniques? Maybe you need to read a book or get training on how to do proper refactoring in your language.
• Testing Know-How: Do you know how to perform unit tests and integration tests in legacy systems? If not, you may need to read a book and/or get training.
• Experiments: Maybe consider doing an experiment as part of your current story or task. Could you do 1% or 10% more to improve the existing code? Maybe add 1 new test? Maybe refactor 1 method?
• Science: Think about where the gap is. Do you know how to do it? On breaking a big problem into a small one? In accepting that you have the power and can do things differently?
• Reflection: Pearhaps a meeting to discuss with your team where and how you could start? (often called retrospective — but we dont need to use this name).
• Just Do it: Maybe you are fooling yourself and making a lot of excuses; maybe do it and see what happens. Maybe starting is easier than you thought. The best time to start is now.

Going to space is not easy and will never be. Refactoring is the same. It will need to be easy, but just because it’s hard does not mean we should ignore it.

Originally published at http://diego-pacheco.blogspot.com on April 30, 2024.