What are the best ways to reduce technical debt?

Everything listed here is valid but really only targets the symptom. The single most important lever to address tech debt is proper design. That means, to have a thorough understanding of the implications that certain design decisions have, where they create a lock-in effect that will be hard to undo later. Proper design will at times be in conflict with ultra-fast development, but it saves a ton of work in the long run.

All you have to do is assess the codebase regularly to identify areas of technical debt. The second step is to prioritize these issues based on their severity, potential impact, and feasibility of addressing them.

You should firstly define what level of technical debt is acceptable in a MVP model. Allocate a certain percentage of your planned capacity for reducing technical debt, based on priorities. Make sure that introduction of new technical debt remains under control and can be easily tackled. Do not add technical debt that will require a complete rewrite to eliminate it, rather than a future revision.

A strategic approach to balance immediate product needs with the long-term health and scalability of the system. Prioritizing technical debt enables a more sustainable and efficient development process, fostering innovation and minimizing the risk of future disruptions.

The best way is not to accumulate it to begin with. But if it does get accumulated, it must be addressed as soon as possible as part of the regular sprint cadence. The ways to avoid accumulating tech debt is to estimate properly so that you have enough time to properly develop a feature without cutting corners, think about a solution and properly design it before coding it and have others review your code early on.

Debt Quadrant way seems to be right when we try to fix the tech Debt proactively but more often it comes during remediation , migrations , tech upgrades , vulnerability , Product out of support etc. , some of these are market driven factors . In such cases urgency becomes a necessity and then its oblivious to miss the right categorization. In such cases , i think it is more important to keep an sharp Hawk eye on technology evolution and access our applications and code base every quarter at least once

This is a team effort where every stakeholder plays crucial role as stated below: 1. via Product Team: Check with Product team on the usage pattern of each functionality. If functionality hasn't been used by users/clients since more than a year, it is obsolete and adds no value. Add that to product backlog to remove such code in place. This should be continuous exercise, should be planned at least once in a month 2. via QA Automation: This adds additional quality gate check where if any automation is failing, it gives opportunity to talk to product to check the functionality usage. AS stated in 1st point which is manual process, this steps is more of automated process. 3. via Automation: Have CICD integrated checks to check for dead code.

As rightly mentioned by others, 1) The goal should be to not have it. 2) Even if introduced, Teams should enabled to get rid of it as quickly as possible. Additionally, In my experience, Once you identify the technical debt and the related areas, you should look for some key metrices, such as 1) What is the frequency of change in that area of code-base? 2) Is the area of code/test a part of the system, where your product generates most value for your users and revenue for your company? 3) What is the cost of change, at the point you identify the area of technical debt (more cost later in the timeline)? I think this is the good starting point to start prioritizing the technical debt and add the value to the system from customer standpoint.

This is a unrealistic and impractical . IT teams mostly do not have efforts and time to update code regularly once it is under production and working. Though security vulnerabilities can be addressed (As its urgent task) but others do take a back seat

Definitely, All this article is under assumption that Devops and Agile are there and in a matured way, I could not imagine Quality Software development without a controlled and regulated devops process

Coding standards and Guidelines help but again practically too many deviations from the guidelines are a challenge during tech debt reduction

Applying current coding standards to a legacy codebase can be challenging but worth evaluating if enforced by a linter and formatter with auto-fixing capabilities. Applying bulk changes can obscure history. Academic perfection is less critical than maintainability, so if using coding standards achieves that goal, it's worth the cost.

Part of that investment should include the budget and prioritization to implement any findings and learnings - it can be frustrating if you empower something with knowledge but don't let them apply it! Check out "Tech on the Go: Owning Legacy Software" in the LinkedIn Learning library, filled with strategies and tales of woe and success in managing legacy software projects.