Why having Technical Debt is good?

Doesn’t the title feel counter-intuitive? Everyone on the internet is just blaming people who had added spaghetti, non-readable, non-maintainable mess of what they call code. Now it’s making life miserable for the newly inducted Engineers and Product Managers.

To be honest, these people who are blaming the early employees aren’t wrong at all. These early people had made a mess of the Product, and now the onus is upon the newer set to clean up the mess and move forward.

But if this was going to be an article blaming the people for the mess they have created, I wouldn’t be adding a new perspective, rather just echoing what has already been said by many engineers before me. Rather I am going to shed light on why and how it was done in the first place, and when you should start considering refactoring your code/product.

A Detour into the Dark Corners of the Spaggetti

A senior folk in a successful startup once said, and I repeat -

We trust our developers, whatever decisions they had taken given any point in time were the best as per the circumstances and situations. If the decisions now seem absurd, that is because the circumstances and situations have changed. Sometimes it is extremely hard to envision the future no matter your experience.

If you have never built products from absolute scratch, it might be difficult to appreciate the statement. Businesses develop over time, sometimes it pivot, faster than we can even anticipate. To appreciate this statement, have the lens of a Business Owner rather than just an engineer. Sometimes we just need to widen our lens, zoom out and have a bird’s eye view of the Business and the Product we are developing.

Let me take you on a slight philosophical detour. Check out the next image of World War 1

What we see is chaos, people trying to take out each other, countries trying to take out each other. Seems quite an important historical event in human history. Let’s zoom out a little to the edge of our solar system, and check out another image -

This is an image of Earth taken by Voyager 1 Space Probe at the outer edge of the furthest planets in our Solar System. At this scale, suddenly, the 1st image feels quite insignificant. Suddenly those tiny land masses we try to fight for feel insignificant.

Let’s get back to our discussion, from this analogy, what I am trying to depict is that sometimes we work in such niche areas that we completely ignore the bigger picture (the business, the overall product), and hence sometimes it’s important for the everyone to zoom-out, change the lens and see the bigger picture to appreciate the importance of all the spaghetti code lying in the the darkest corners of the codebase. Sometimes we need to zoom out to start asking “more” important questions.

It served a purpose once, it’s legacy, it is due to that piece of code, we reached where we are today. Hence it becomes our collective responsibility to clean it up.

What is Technical Debt?

As per definition -

Technical debt is a common concept in software development, where team leaders delay features and functionality, cut corners, or settle for suboptimal performance to push the project forward. It occurs as the result of a “build now, fix later” mentality. In software engineering, tech debt is sometimes called code debt.

In easier words, after a decade of experience in the field, I define Tech Debt as -

1. Add another field in the table for the time being, we will figure it out later.
2. Add another if condition in the Search function, we will refactor the function later. (it’s ok even if the function is 900 LOC).
3. This feature is no longer required, let’s not remove the code as of now, as it might break some existing functionality.
4. Let’s not use ElasticSearch as of now, see if we can move along with SQL queries.
5. We can build the microservice later, let’s build the feature in this repo itself.
6. Let’s horizontally scale the Django Microservice since we are experiencing increased load. Yes, it is resource-intensive, we can burn some cash for faster development, and we can migrate to Golang later.
7. Let’s build faster, we can write the Test cases later.

And many more, you get the gist.

I divide these statements into 2 categories -

• Lack of knowledge, due to which what can be done the right way today itself is postponed to some later stage with a current suboptimal solution.
• Things that literally can’t be done right now, and require more effort and resources.

As you can imagine, there’s no defined segregation between the two categories. As you gain experience, you tend to do things in a better way, and hence your tech debt decreases. (Stress on the fact that I wrote “Better” and not “right”, Being right is subjective).

As you gain experience both in terms of Technical Expertise, and Business/Product acumen you tend to make more informed decisions which will greatly reduce the amount of tech debt you incur as you move along.

One of the best ways to gain knowledge in terms of Tech Expertise is to understand the inner workings of the systems you use daily, just try to pop the hood once in a while to see how it works. e.g.

• Understanding different design patterns to help you write better code — https://refactoring.guru/design-patterns
• SOLID Principles — https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/
• Low-Level Designs — https://www.youtube.com/results?search_query=lld+system+design
• High-Level Designs — there’s plenty on YT on the same subject, follow anything at your convenience.
• Database Engineering — https://www.youtube.com/watch?v=pomxJOFVcQs&list=PLQnljOFTspQXjD0HOzN7P2tgzu7scWpl2

When should you start worrying about Technical Debt?

After spending a decade in the Startup world, making mistakes along the way, and learning from them, here are the signs I figured when you should start worrying about tech debt -

• Your MVP is out. (Minimum Viable Product)
• You have figured out PMF (Product Market Fit).
• You are getting a steady Revenue.
• You are getting complaints of Application slowness, and bug reporting every week due to legacy systems.

If any of the above do not check out, there’s still time for the product/business to develop/pivot/deviate from their original thesis. Hang tight, let them figure it out.

How to handle Technical Debt once identified?

Identifying when to start working on the technical debt is the most difficult part, the next part is the easy.

Your systems are working as intended, your revenue stream is sorted, and it all boils down to better UX and code maintainability. Most of the time handling tech debt is not time-bound from Business/Product (they don’t even care). It is upon the Engineering team to take care of it. I found 2 ways to handle -

• Have an entire Sprint in a Quarter to take care of it (Brutally Prioritise all the tasks related to Tech debt in a separate Epic of the Product Project in Jira). Pick up tasks from such an Epic priority-wise, and keep squashing the bugs. In addition to this, you can also pick up these tasks every sprint as per your team’s bandwidth and the priority list.
• Interns — Assign an intern to the major tech overhaul and a mentor to guide them along the way. It’s a win-win situation if you think about it. Sometimes when tech debt is not time-bound, an intern can pitch in for it, a mentor can guide them with Task creation and tech guidance, while interns can execute them gaining experience and confidence along the way. This has a double effect, Interns gain experience, Tech debt gets squashed.

Summary & Conclusion

As you move along in the product development, there will be stricter processes, and hence lesser chances for the Tech Debt to creep in, however, the system is not full-proof, we are humans (until AI takes over) and we will make mistakes, but having processes as you mature as an Organisation is extremely important. Few that I can tell for the current context -

• Technical Design Document & Peer Reviews.
• Test Driven Development.
• Stricter Quality Analysis (Software Testing).
• Software Metrics, bug reporting/monitoring, Application Monitoring.
• Design Patterns & LLD.

As you mature as a Developer/Person, you tend to gain experience, try to impart that wisdom to the team and don’t be lazy : )

Try to have OCD for doing things the right way. And how to know what is the right thing? Well, just keep building/breaking/reading/learning from your and other’s experiences. Just don’t stop!

PS: This is my experience and perspective, I would be happy to understand yours. If you have suggestions/doubts, please feel free to comment. Always up for learning something new. Until next time : )