Contents
Technical debt is a way of discussing internal software quality in terms of the extra work it creates for future changes. The useful question is what that means for the system you depend on: which changes are difficult, which risks are material and what intervention would improve the situation. Start with observable problems rather than treating the age of the code as a diagnosis.
What technical debt means
Martin Fowler describes technical debt as a metaphor for internal deficiencies that make software harder to modify. The extra effort is the interest; improving the underlying structure is analogous to repaying principal. His explanation also cautions that these costs are estimates rather than precisely measurable financial amounts.
Use the term to make a decision more concrete. If a team says a reporting feature is blocked by technical debt, ask which part of the implementation causes the difficulty and what evidence supports that assessment. The next conversation should identify a problem the team can investigate or change.
Connect symptoms to specific causes
Collect examples from recent work: a change that required edits in several unexpected places, a release that needed repeated manual repair, or a calculation whose intended behaviour was unclear. Record the task, the difficulty and the consequence. Avoid attributing every delay or defect to the same cause.
Check alternative explanations. A slow decision may come from unclear product ownership. A missing feature may simply be unimplemented scope. An incident may need immediate containment regardless of whether the code has structural problems. Classifying the issue helps the team choose an appropriate response instead of building an undifferentiated list of things it dislikes.
Ask developers and operational users to compare their observations. A workaround that is invisible in source code may consume substantial user effort. Equally, an internal complication may have little relevance to the next business priority. Use both perspectives to decide what deserves attention.
Prioritise against the work ahead
Take the next planned product changes and identify the parts of the system they touch. For each concern, describe the likely effect on those changes, the uncertainty in that assessment and the smallest investigation needed. Keep urgent security or reliability work visible in its own right rather than requiring it to compete solely on feature-delivery savings.
Create a short decision record for a candidate improvement: the observed problem, the proposed intervention, the behaviour that must remain intact and the result you expect. Include the cost of testing and release. An improvement is easier to evaluate when the team can show what it is intended to enable.
Choose an intervention with a clear boundary
An intervention might clarify a poorly understood calculation, establish tests around a critical workflow or separate one integration from unrelated code. Define a boundary that can be reviewed and released. Explain which behaviour should stay the same and which visible change, if any, is intended.
If replacement is being considered, assess the migration and operating plan as well as the proposed new implementation. List the records, integrations and exceptional cases that must survive the move. A new codebase does not remove the need to understand the business rules already embedded in the existing product.
Agree how the result will be checked before work starts. The receiving team should be able to demonstrate the relevant user journeys and explain how it would recover from a failed release. Keep the evidence attached to the change so later maintainers can understand why it was made.
Plan the next step and review its effect
Choose one material concern and gather enough evidence to decide whether to act. Assign an owner, define the investigation and set a review point. If the team recommends a broader programme, ask it to show the sequence of useful outcomes and the dependencies between them.
After an intervention, review the next relevant change or release. Did the original difficulty recur? Was the work easier to explain and verify? Record what remains uncertain rather than claiming a precise return from a single observation. Use that evidence to choose the next priority.
A symptom-to-debt exercise for a business owner
Consider a fictional booking business where every price change needs three code edits, staff reconcile repeated bookings each Friday and releases depend on one developer. These are symptoms, not yet a diagnosis. Record the desired change, the obstacle, the observed business effect and the evidence needed to confirm its cause. The three-edit problem might be duplicated pricing rules; repeated bookings might instead come from an external retry or a misunderstood process.
Build a small register: duplicated pricing rules → change risk → inspect one price change and its tests; manual reconciliation → staff time → trace five controlled examples; single-person releases → continuity risk → ask a second authorised maintainer to follow the release guide. Give each investigation an owner and a decision. Do not label every inconvenient feature or old dependency technical debt.
Separate intentional trade-offs from defects. A temporary manual export may be acceptable during a pilot if its owner, limit and replacement trigger are recorded. An unexplained permission failure needs a corrective action, not merely a debt label. Use the costing guide once the recurring burden is observed; use the refactor-or-rebuild guide only when you have evidence about how much of the system remains useful.
How this relates to Veda Software’s work
Encounter’s move from paper-based trip preparation to managed information illustrates a process burden worth investigating. The published story does not diagnose code debt or quantify the cost of a particular defect.