Pay or not to pay Tech Debt

Tech Debt is always ignored under the pretext of funds and resource unavailability. Adding features to big ball of mud is always preferred.
I worked on one product where one main component has really high tech debt. Developers and company spending on that tech debt more than anything. But the company management prefer beating around the bush rather than handling the BIG tech debt. I came to know that they are still fixing bugs. Happy I am not there 😊

Problems

1. New features estimates are way higher than they need to be. Or, impossible altogether.
2. Bad code spawns more bad code.
3. Bug list grows even if developers are always fixing them
4. The good/best team members are leaving
5. Documentation and implementation are totally out of sync.
6. What you see as a bug the users see as a feature 😂
7. Conversely many “features” will be viewed as defects by the users.😒
8. It leads to Lack of Ownership.
9. More investment on support and maintenance.

Tech debt is increasing

According to Consortium for Information & Software Quality™ (CISQ™) report the growing impact of Technical Debt (TD) has become the biggest obstacle to making any changes to existing code bases.
• TD principle increased to ~$1.52 trillion (because deficiencies are not getting fixed).
• In spite of a projected rate of 15% growth in computer/IT positions created over the next decade,
the number unfilled US IT jobs sat at about 300,000 at the end of August
• In late 2019 it was predicted that by 2025,40 % of IT budgets will be spent simply maintaining TD,
and it’s a primary reason that many modernization projects fail.
• The number of weekly hours an average developer at a company spends on addressing “TD” is 13.5
out of 41.1, or 33% of their time.

MITRE recently shared their top 25 most common and dangerous weaknesses impacting software

How to decide?

1. Will this code get modified a lot in the future?
2. Is this debt in the way of a key feature?
3. Existing code was in a no longer supported tool chain, (MicroPower Pascal), that only ran on nearly unsupportable development platform, (PDP11–23).
4. Finding developers who could work on tools and targets was becoming almost impossible.
5. The target hardware was no longer available.
6. Issues in the code were resulting in readily identifiable customer dissatisfaction and direct servicing costs.
7. Build time is in hours.

When to ignore?

1. Client never plan to use the software longer than a year.
2. The code is still maintainable, testable.
3. Need almost no modification.
4. Working fine and supported by tool chain.
5. Not a critical component and can be developed in one quarter.
6. Used by internal team to increase productivity and right now working fine.

In some cases ignoring the tech debt is possible for some time but debt is debt. Technical debt, like credit card debt, is an investment in getting customers faster and gaining market share over your competitors faster. Like credit, if managed properly, it can make you quite successful.

Ways to convince client to pay it off.

1. Sell it as business risk
   Businesses used to understand it in terms of revenue. Tell them it can cause security end-point vulnerabilities, opening the company to security breaches that threaten company revenues and reputation, and that will also lead to increases in business and cyber liability coverages and in high future costs.
2. Align technical improvements to business outcomes
   Addressing technical debt can result in better business outcomes, higher velocity, improved team morale, increased team retention, and alignment with values.”
   Increasing test coverage, addressing data quality, documenting architectures, and increasing observability are examples of non-blocking improvements that require ongoing enhancements.
   When product managers see technical teams prioritize, define their issues in business terms, and create meaningful agile principles, they are more likely to support improvements that address technical debt.
3. Show amount of testing and bug fixing effort (especially for fixing regression bugs) needed for successful delivery to Client/management
4. Another way:
   I include that in my estimate. For example, “This bug will take me 2–3 days to track down, but if we had already addressed these 2 other ‘low priority’ bugs that have been in the queue forever, it would probably take less than one.” Often, the response will be to go ahead and fix those other ones while you’re at it.

References

https://www.infoworld.com/article/3636159/convincing-agile-product-owners-to-prioritize-technical-debt.html

https://www.it-cisq.org/overview/

https://softwareengineering.stackexchange.com/questions/50819/is-there-a-measure-of-code-rot?noredirect=1&lq=1

https://betterprogramming.pub/should-you-invest-in-software-quality-or-speed-68904fa993e