Technical Debt | What, when & How's of it.

Technical Debt is a term when we have lots of code that is not fit to take in more changes, adding something new just breaks or disrupts the existing working flow.

Typically when a piece of code, tries to do too-many things, it grows like ameoba and sooner we reach a point where code-refactoring or entire module needs to be re-written.

If overlooked for too long we end up with rigid softwares and that cannot do new things, to be able to do something new we need to refactor it , and this process is called technical debt reduction.

Ways to Identify it

If new requirements cannot be coded, with no or minimal impact. Understand the code is not modular & extensible enough.

When a systems component needs to be changes or updated because of new changes, like moving to a new messaging queue or database. Understand the old code-to-system coupling was not future thinked. Sometimes its hard to predict that, but most of the time systems should work with new requirements.

Strategies to Solve it

One high level approach is to not fix it, instead write a new piece of code separatly as microservice and orchastragte the overall all api flows to achive the desired outcome. This way we dont tough the working but high-tech debt module.

Another approach is to re-write that old piece of software with new tech and typically eliminating any old tech-debts from it. As technology advances there comes doing things diffrently, better & cheaper. At this point of time its prefrerable to redo things in new, cheap & improved ways. example all the old monolith software can see significant boost in high-load performance when split into microservices and dockerised for auto-scaling.

obviously there is no silver bullet in tech that works for all the use-cases. One counter example to this is when Amazon Prime Videos moved out from microservices architecture to monolith, thier main emphasis was to be able to serve content living in CDN and managing the user requests from vertically scaled monolith application. Idea was they know exactly how many users have subcribed to amazon prime services and in each zone whats the max user load so they can tune their servers to handel the users.

I case of any dynamica load applications like socialmedia apps, this wouldn't have worked.

And the most used strategy is to refactor the code on regular intervals, follow desing patterns and anti-patterns/code smells. Now here come the catch that about what % of effort should be allocated to refactoring, it-depends. Personally I am not comfortable with anything more than 10% effort allocation, some teams do 5% and some upto 25%.