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 it's a technology problem, and 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)

Planet Earth

IF you said "yes" " it's a pretty good and reasonable answer. But that is not accurate, at least not anymore. Maybe if we asked such a question in the 50s, it would be correct. 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 just 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 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 and 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.
A lot of people think they can only fix a problem if they have time and a specific project to work on such a problem. 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 just 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 just need to push back. Consider getting 1 more day in your task to do some refactorings, maybe?
  • 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 do unit tests and integration tests in legacy systems? If not, maybe you 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 is the gap? 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 just 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. 

Cheers,
Diego Pacheco

Popular posts from this blog

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all language...
Keep reading

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail...
read more »