Free calculator · Engineering
A 10-question technical debt and codebase health scorecard
Answer 10 questions, two each on delivery, testing, data, security and knowledge. Each answer scores 0 to 3, giving a score out of 30, a band from critical to healthy, and the three weakest areas with a next step for each.
How this is calculated
You answer 10 questions, two in each of five dimensions. Each answer scores 0 to 3, and the score is your points out of 30. The questions draw on DORA's capability guides and OWASP's cheat sheets; the scoring and bands are QuantmHill's own convention.
Step by step
- Score each answer: 3 for the healthiest option down to 0 for the least healthy.
- Add the points: the score is the total divided by 30.
- Band: healthy at 80% or more, manageable from 60% to below 80%, accumulating from 40% to below 60%, critical below 40%.
- Score each dimension out of 6 from its two questions.
- Priorities: the three dimensions with the fewest points, weakest first; ties go to the dimension listed earlier. Each shows the weaker of its two answers.
Default assumptions
Assumptions marked adjustable can be changed in the calculator; the others are fixed parts of the model.
| Assumption | Default | Sources |
|---|---|---|
| Starting answer: how often can you release the main product to productionadjustable | Between once a day and once a week | |
| Starting answer: how long does a typical change take from commit to running in productionadjustable | Between a week and a month | |
| Starting answer: how well do automated tests cover the business logic that matters mostadjustable | Some critical paths are covered; tests run on every change | |
| Starting answer: when the automated test suite fails, what does it usually meanadjustable | Often a flaky test, so failures tend to be ignored | |
| Starting answer: how are database schema changes madeadjustable | Versioned migrations in version control, applied by hand | |
| Starting answer: how well do you understand how the production database performsadjustable | We look only when users complain | |
| Starting answer: how are third-party dependencies kept up to dateadjustable | Vulnerability scanning in CI, with updates batched now and then | |
| Starting answer: how are secrets such as api keys and database passwords handledadjustable | Environment files passed between people | |
| Starting answer: where are architecture decisions and how the system works written downadjustable | A wiki that is mostly up to date | |
| Starting answer: how many people could safely change each critical part of the systemadjustable | Only one for some critical parts |
What this doesn’t model
- It is a self-assessment and doesn't inspect code, pipelines or production data.
- Every question carries the same weight, whatever matters most for your product.
- Ten questions can't cover everything: architecture coupling, code complexity, performance and accessibility aren't asked about.
- The bands are a planning aid chosen by QuantmHill, not a published benchmark.
- Nothing here estimates cost, hours or a remediation timeline.
Sources
- DORA, DORA's software delivery performance metrics. Accessed . Defines change lead time and deployment frequency, which the delivery questions use.
- DORA, Capabilities: Continuous delivery. Accessed . The ability to release changes of all kinds on demand quickly, safely and sustainably.
- DORA, Capabilities: Test automation. Accessed . Fast feedback on every change from reliable automated tests.
- DORA, Capabilities: Database change management. Accessed . Database changes are often a major source of risk and delay in deployments.
- DORA, Capabilities: Monitoring and observability. Accessed .
- OWASP Cheat Sheet Series, Vulnerable Dependency Management Cheat Sheet. Accessed .
- OWASP Cheat Sheet Series, Secrets Management Cheat Sheet. Accessed .
- DORA, Capabilities: Documentation quality. Accessed . DORA's analysis links documentation quality with organisational performance.
- DORA, Capabilities: Code maintainability. Accessed .
- Martin Fowler, Technical Debt (21 May 2019). Accessed . Technical debt as the extra effort ('interest') that deficiencies in internal quality add to future changes.
Last reviewed by the QuantmHill engineering team. Found an error?
Link to or cite this tool
Writing about this topic? Link to the calculator or cite it. Its method, defaults and sources are all on this page, so readers can check the numbers.
Embed this calculator
You can put this calculator on your own site for free. Paste the code below where it should appear. It loads the same calculator in a frame, with a link back to this page for the full method and sources.
The credit line links to this page with the anchor text “QuantmHill”. You may edit it, add rel="nofollow" or remove it — the calculator works the same either way. Add ?theme=light or ?theme=dark to the iframe address to fix its colour scheme; otherwise it follows the visitor's system setting.
Add this once per page, after the iframe, if you want the frame to grow and shrink with the calculator instead of using the fixed height above. It accepts messages from quantmhill.com only and resizes only the frame that sent them.
Frequently asked questions
Each of the 10 questions has four answers scored 3, 2, 1 or 0. The score is your points divided by 30. The bands are healthy at 80% or more, manageable from 60%, accumulating from 40% and critical below 40%. The weights and bands are our own convention, not an industry standard.
Anything about how the system is built and run that makes the next change slower or riskier than it needs to be: slow or manual releases, unreliable tests, hand-run schema changes, unmanaged dependencies and secrets, and knowledge held by one person. Martin Fowler describes this extra effort as the interest paid on the debt.
They are the three dimensions with the fewest points, weakest first. When two dimensions score the same, the one listed earlier (delivery, testing, data, security, knowledge) comes first. For each, the tool shows your weaker answer and a next step.
The delivery, testing, data and documentation questions follow DORA's capability guides, such as continuous delivery, test automation and database change management. The security questions follow OWASP's cheat sheets on dependency and secrets management.
No. It is a self-assessment from your answers and doesn't read your code. A review of the codebase, pipeline and production metrics would show where the debt actually sits and what it costs to change.
Want an engineer to check your numbers?
Send us your inputs and the decision you're weighing. We'll reply within one business day with an honest read on whether we can help.