Knowledgebase

Technical Debt: Everything That Matters, Briefly Print

  • softwareengineering, software, hacked, security, performance, troubleshooting, guide, howto
  • 0

The summary.

ONLY DELIBERATE, RECORDED COMPROMISE IS ACTUALLY DEBT

Conflating it with everything anyone dislikes about a codebase makes the conversation useless.

Old code that works and is rarely changed costs near nothing, whatever it looks like.

WHAT COSTS MOST IS WHERE CHANGE AND DIFFICULTY MEET

Look for areas everyone avoids, changes that consistently overrun, and where defects cluster.

Ask what it is costing. If the answer is nothing, leave it.

REQUESTING A PERIOD TO FIX EVERYTHING DOES NOT WORK

It is rarely granted and cancelled when priorities change. Allocate a consistent proportion of capacity instead — sporadic effort is always displaced by delivery pressure.

Refactor before a feature, not after: make the change easy, then make the easy change.

JUSTIFY IT WITH DELIVERY SPEED, DEFECT RATES AND RISK

Technical arguments do not persuade people who allocate time.

NOTHING IS AS PERMANENT AS A TEMPORARY SOLUTION

Record what was compromised, why, and when it will be addressed — in the code itself.

SECURITY, DATA INTEGRITY AND ANYTHING TOUCHING MONEY ARE NOT DEBT

They are defects.


Was this answer helpful?
Back

Are you happy with your experience? Leave us a review on Trustpilot.


Trustpilot