Forem

Sabbir Siddiqui
Sabbir Siddiqui

Posted on

2 1

How to deal with Technical Debt

As per Wikipedia,

In software development, technical debt (also known as design debt[1] or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

As per my opinion and / or experience, there are two kinds of technical debt - intentional and unintentional ones.

The unintentional ones stem from technical decisions that may not take the big picture in mind, where the engineer is unaware of the debt they are creating for the future. These can happen due to lack of context, lack of experience, or lack of proper impact analysis, or you know just plain human error (we are all human). Processes like pair programming, diligent PR reviews, or allocating more time on task design may be a way to mitigate these kind of issues.

The intentional ones are from deliberate engineering decisions. A team or someone decided to implement something they knew they would need to fix or refactor in the future, but decided to go ahead with it anyway due to time / deadline / business constraints. Meaning, if there is a debt, it's there for a reason, and has been put on the back-burner along with the others.

No system is perfect, and in any growing product / software, especially startups, the latter tends to happen for shorter time-to-market. "For now we will do X to solve the problem, but in the future we should do it Y to make it more generic and scalable".

Now, how to manage this debt? Like any other debt, tech debt can and should be paid in instalments. It's important for tech leads and engineering managers to be aware of tech debt, have a prioritized backlog of the same, and try to incrementally get rid of the debt over time by introducing reworks / refactors / implementations within the Sprint or regular development process as a part of normal tasks. The prioritization would happen based on a combination of business need vs which is more likely to degrade system health in the near future.

It is also the responsibility of technical leadership to collaborate with and persuade product managers / business teams on considering the additional time towards tech debt before delivering a requested feature.

For example, let's say there are some new requirements regarding SMS notifications, and the current notification system needs an overhaul. A plea to product managers would be "I know we are trying to achieve ABC with this feature to facilitate growth, however we need some time to refactor our notification system. This will allow us to implement any new notification requirements easily, plus make the notification system more scalable. If we don't do this now, with the growing number of notifications, it will degrade our performance by X hence affecting growth."

At the end of the day, both tech and business parties should work together, and be aware of the importance of technical debt, how it can affect the current system, and hence the current business. The idea is we are all working together towards a common goal.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read more →

Top comments (0)

Billboard image

The Next Generation Developer Platform

Coherence is the first Platform-as-a-Service you can control. Unlike "black-box" platforms that are opinionated about the infra you can deploy, Coherence is powered by CNC, the open-source IaC framework, which offers limitless customization.

Learn more

👋 Kindness is contagious

Engage with a sea of insights in this enlightening article, highly esteemed within the encouraging DEV Community. Programmers of every skill level are invited to participate and enrich our shared knowledge.

A simple "thank you" can uplift someone's spirits. Express your appreciation in the comments section!

On DEV, sharing knowledge smooths our journey and strengthens our community bonds. Found this useful? A brief thank you to the author can mean a lot.

Okay