Tech Debt First

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 https://diego-pacheco.blogspot.com on April 30, 2024.

要查看或添加评论,请登录

Diego Pacheco的更多文章

  • The Dark Side of LLMs: part 2

    The Dark Side of LLMs: part 2

    July 2024: I wrote the first blog post about The Dark Side of LLMs. During these 7 months, many things have changed;…

  • The Monk and The Rockstar

    The Monk and The Rockstar

    I have been doing practical and real software architecture for more than 20+ years. Software architecture is a great…

    4 条评论
  • The Issue with Feedbacks

    The Issue with Feedbacks

    I love feedback. I believe in feedback a lot.

  • Quality Needs to be Managed

    Quality Needs to be Managed

    Quality often means something different to each person. My definition of quality revolves around technical excellence.

  • State

    State

    If you look up on dictionary.com the first two definitions of state are: 1.

  • Leaky Contracts

    Leaky Contracts

    Service contract design is hard. People do it all the time, but it is not always correct.

    2 条评论
  • Services

    Services

    We are in the holiday season. You walk into any Starbucks and see the Christmas decorations.

  • Proprietary Systems and Distributed Monoliths

    Proprietary Systems and Distributed Monoliths

    Distributed Monoliths are the predominant form of modern legacy systems. Sometimes distributed monoliths are created by…

  • Functional Programming

    Functional Programming

    There are many programming languages. Most of them are based on C.

    1 条评论
  • Proper Error Handling

    Proper Error Handling

    No matter what programming languages you use. Engineers need to make dozens to hundreds of small decisions every day.

社区洞察

其他会员也浏览了