You can put a cost on technical debt without reading a line of code. You pay for it every month in places your company already tracks: the wait between a business request and the day it goes live, hours of manual workarounds, incidents, delayed projects, and a few risks nobody has priced yet. To get a number that holds up in a budget committee, track those lines for 30 days from your tickets, schedules and invoices, then add them up as a range.
Which number should you bring to the next budget meeting?
Bring the real lead time of your last three business requests, taken from your IT department's ticket history. Pick out the last three changes delivered at a business team's request, say a new field on a form or a new report, and count for each one the working days between the request and the day the change went into production. Everyone on the committee reads that number the same way.
Then ask the business team how they managed while they waited. The answer is often a spreadsheet kept on the side of the system. That spreadsheet is your first hidden cost.
Why doesn't "the system is old" get a budget approved?
A leadership committee chooses between amounts of money, and the age of a system isn't one. When someone asks for a rebuild, finance asks a fair question back. What do we lose if we wait another year?
The original metaphor helps answer it. In an experience report presented at OOPSLA in 1992, Ward Cunningham wrote that "shipping first time code is like going into debt" and that "every minute spent on not-quite-right code counts as interest on that debt." Martin Fowler makes it practical: "The extra effort that it takes to add new features is the interest paid on the debt." You pay the principal (rewriting what was done badly) once. The interest comes back with every request, so that's the part worth measuring.
Code analysis tools such as SonarQube mostly measure the principal. Their debt figure is the sum of estimated fix times for every maintainability issue, counted in minutes. Your CIO can use that. It tells you nothing about the days your maintenance managers spend waiting for a report.
What does technical debt actually cost?
It costs time, for business teams who wait and for developers who work around fragile code, and you pay for that time in manual hours, incidents and licences. On top of that comes the risk of a system that only one person can change, or that the vendor no longer patches, and that can stop for a length of time nobody has estimated.
For a rough order of magnitude, developers surveyed by Stripe and Harris Poll in 2018 in the United States, the UK, France, Germany and Singapore estimated that a developer at their company spends 13.5 hours a week on technical debt, out of a 41.1-hour week. That figure is self-reported, it's eight years old and it wasn't collected in Morocco, so it can't stand in for your own measurement.
Which measure lands best with a leadership committee?
Lead time from business request to go-live is counted in days, and the plant director and the CFO both understand it. Your CIO may know the DORA metrics, which track a related figure called change lead time, from the moment a change is committed to its deployment. For your question, that clock starts too late, because it skips the queue of requests and the back-and-forth over priorities that happen before anyone writes code.
Time four standard requests: a new field on a screen, a new report, a new user profile, a new validation rule. For each one, record the actual lead time and the hours of work the technical team spent on it. A field that takes two hours of work and six weeks on the calendar needs explaining.
Not all of that gap is debt. An industrial case study published in 2024, covering six software components, found mixed effects: depending on the component, technical debt explained between 5% and 41% of the variation in lead time, and the authors suggest that other factors, such as change size, complexity and the number of teams involved, also play a part. That makes time spent waiting for a decision a governance problem, and it gets fixed another way. Extra development and testing time, the kind that piles up when nobody dares touch a module, is the debt.
Also count the decisions postponed for lack of a number in time, such as investment in a second packaging line pushed back a month because nobody trusted the downtime extract. Look for them in the last six months of committee minutes.
Which worksheet should you use for each cost line?
Since a number nobody owns gets challenged, every line has an owner. The loaded hourly cost, which finance provides, is the common multiplier.
| Cost line | Where to find the data | Annual formula | Who owns the number |
|---|---|---|---|
| 1. Extra lead time on business requests | Tickets, emails, production release dates | working days beyond target lead time × requests per year × workaround hours per day × hourly cost | Requesting business unit, with IT |
| 2. Incidents and outages | Incident log, support tickets | (hours down × people blocked + fix hours) × hourly cost | IT operations |
| 3. Manual workarounds and re-keying | Interviews with each team, side spreadsheets | hours per week × working weeks × hourly cost | Each team manager |
| 4. Delayed projects and decisions | Project list, committee minutes | expected annual gain × months of delay ÷ 12, in hours for time saved, in money for revenue | Project office, with financial control |
| 5. Run cost of the obsolete stack | Licence, maintenance and hosting invoices | current annual cost minus the cost of an equivalent up-to-date stack | CFO with IT |
| 6. Dependence on one person | List of modules only one person can change | replacement cost × probability of absence or departure within the year | HR with IT |
| 7. Unsupported versions | Software inventory, vendor end-of-support dates | extended support or forced upgrade, plus a range for a likely incident | CISO or CIO |
An hour counts once. Workaround time while a request waits goes on line 1, ongoing re-keying goes on line 3, and each owner checks that no hour appears on two lines before signing off.
Add up the hours on lines 1 to 4 and convert them to money with the hourly cost. A delayed gain counts in hours only when it is time saved, while expected revenue goes in as money, next to line 5, which the invoices already price for you. Keep the last two lines apart as a low and high range. A CFO will readily accept a measured hour, far less readily a probability.
For line seven, end-of-support dates are public. Microsoft, for instance, stopped standard security updates for Windows Server 2012 and 2012 R2 on 10 October 2023.
How do you run the measurement in 30 days?
You don't need a code audit or a new tool. You need a few hours a week from IT, two or three business units and financial control.
| Period | What you do | Who does it |
|---|---|---|
| Week 1 | Name an owner for each line, get the hourly cost, pick the standard requests | CEO or CIO, CFO |
| Week 2 | Date the changes delivered in the last six months, track every new request | IT, business units |
| Week 3 | Interview teams about workarounds, pull incidents and invoices, list end-of-support dates | Team managers, IT, finance |
| Week 4 | Read committee minutes, fill in the worksheet, have each owner sign off their line | Financial control |
| Day 30 | One page with the annual total, the two heaviest lines and the two risks | CIO and CFO together |
Once that's done, keep tracking the four standard requests every quarter and redo the full worksheet once a year, at budget time.
How many hours does the worksheet turn up in a factory?
A factory plans its production and maintenance on an ageing system, linked to the ERP by a home-built interface. This factory is fictional. Every value below is an assumption made to show the arithmetic, and none of it describes a real company or a market average.
| Line | Example assumptions | Hours per year |
|---|---|---|
| Lead time on requests | 40 requests a year, target of 10 working days, 35 working days measured, one hour of workaround per extra working day of waiting | 40 × 25 × 1 = 1,000 |
| Ongoing re-keying | 3 planners re-keying production orders, 5 hours a week each, 45 weeks | 3 × 5 × 45 = 675 |
| Incidents | 6 outages of 4 hours, 25 people blocked, 12 fix hours per outage | 6 × (4 × 25 + 12) = 672 |
| Delayed project | Automated preventive maintenance scheduling pushed back six months, expected gain of 1,500 hours a year | 1,500 × 6 ÷ 12 = 750 |
| Measured total | 3,097 |
To turn hours into jobs, the example starts from Morocco's Labour Code, which sets normal working time outside agriculture at 44 hours a week, or 2,288 hours a year. After leave and public holidays it keeps 45 working weeks, as on the re-keying line, which gives about 1,980 hours per person. The 3,097 hours are a little over one and a half full-time jobs, lost or not yet gained, since 750 of them are a gain the delayed project hasn't delivered. Multiply the hours by the loaded hourly cost and you have the annual interest. With no price yet for an up-to-date stack, the run-cost line stays empty.
The two risks go on the same page without being added to the hours. Only one person knows how to change the interface between the planning system and the ERP, and the server it runs on is Windows Server 2012. The committee now has about 3,100 hours a year and two dated risks to set against what it would take to fix the two heaviest lines.
What do you do with the number once you have it?
Use it to choose a scope. In many information systems the most expensive debt sits between applications, in the nightly export to accounting or the interface nobody documented, and that boundary is what you repair. Our piece on process-based architecture shows how to find those boundaries before deciding what to fix.
Start with the two or three lines whose annual cost is highest compared with what it would take to reduce them. Rewriting an interface or isolating a module is custom development work, and you track the result with the same worksheet. If the worksheet shows the whole stack weighing on every line, compare the options in our guide to information system modernization, this time with a number in hand.
FAQ
- Who should run this, IT or finance?
Give it to both, with different jobs. IT supplies the dates, the incidents and the software inventory, while finance supplies the loaded hourly cost and checks the formulas. When IT runs the exercise alone, people tend to suspect it is arguing for its own budget. A CIO and a CFO presenting the same page are much harder to argue with.
- How do we find the dates if our requests don't go through a ticketing tool?
Email is enough to start. The date of the first message making the request and the date of the message announcing go-live give you a usable lead time, even a rough one. Rebuild a dozen recent requests that way, then open a shared spreadsheet where every new request gets a date in and a date out.
- What if the technical team disputes the figures?
Ask them to correct the worksheet instead of rejecting it. With every line showing its source and formula, a disagreement comes down to one specific assumption, such as workaround hours, and gets settled by checking the data. The technical team has a stake in this as well, since it turns their complaint about an old system into a case a committee can fund.
Sources
- Ward Cunningham, OOPSLA 1992 experience report
- Martin Fowler, Technical Debt
- DORA, software delivery metrics
- SonarQube, code metrics definitions
- Stripe, The Developer Coefficient (2018)
- Paudel et al., technical debt and lead time (2024)
- Microsoft, Windows Server 2012 end of support
- Moroccan Labour Code, article 184 (Ministry of Justice, French text)
Last verified: 1 November 2026.
We can fill in this worksheet with your line owners during a free audit if your teams can't spare the time to collect the data. One date on line seven has already passed. Extended Security Updates for Windows Server 2012 and 2012 R2, which companies running their own servers had to buy, ended on 13 October 2026.
