Technical Debt Research and Citations
Technical debt has a real literature. It starts with one paragraph in a 1992 conference report and runs through peer-reviewed theory, empirical surveys, and a consensus definition agreed by the research community.
This is the bibliography behind everything on this site: full citations, what each source actually argues, and why it matters. Also here, and just as important, is the list of sources we deliberately refuse to cite.
How This Site Sources Its Claims
A site whose entire argument is that real numbers get budget cannot ship invented ones. So the sourcing rules here are mechanical rather than aspirational, and a build gate enforces them:
- Every statistic resolves to a registry entry. Each cited source lives in a single shared file recording the publisher, the exact title, the year, an absolute link, the date it was accessed, and a quotation actually read at that link. A source you cannot quote is a source you did not read.
- Every statistic carries a publisher and a year on the page. Not "studies show". Not "research suggests". The name of the organization and the year of publication appear in the visible text, so a reader can check the claim without opening a link.
- Unverifiable claims get deleted, not reattributed. When a figure cannot be traced to a real publication, the sentence goes. Stripping a fake footnote and leaving the assertion standing as a bare claim hides the problem instead of fixing it.
- Vendor research is labelled as vendor research. A tool vendor measuring the benefit of its own tool is a legitimate data point and a conflicted one. Both facts get stated.
- Surveys carry their sample. A percentage means nothing without who was asked, how many, when, and by whom. Fielding dates matter enormously in a field moving this quickly.
- Report errors and they get fixed at the source. Corrections are applied to the registry, which propagates to every page drawing on the same entry. Use the contact page with the page URL, the sentence, and the source you believe is correct.
Why the rules are this specific. They were written after an internal audit found roughly three dozen attribution failures across this site: reports that did not exist, quotes attributed to documentation that never contained them, and figures mislabelled by years. In one case a productivity number was credited to the wrong publisher and pointed in the opposite direction from the actual finding. Every one of those is now blocked by an automated check rather than by good intentions.
Origins: Where the Metaphor Came From
Four sources define the prehistory and the founding moment. Two predate the metaphor and explain why software decays at all; two are the metaphor itself and its author's later correction.
Cunningham, 1992 - The WyCash Portfolio Management System
Ward Cunningham. "The WyCash Portfolio Management System." Experience report, Addendum to the Proceedings of OOPSLA '92, ACM, 1992, pp. 29-30. DOI 10.1145/157709.157715. Author's copy at c2.com/doc/oopsla92.html.
This is the origin of the technical debt metaphor, and it surprises most people who read it for the first time. It is a product experience report about WyCASH+, a cash portfolio management system written in Smalltalk, and the metaphor occupies a single short paragraph that begins "Shipping first time code is like going into debt." Cunningham's argument is not about sloppy code at all; it is a justification for incremental delivery. Shipping code that reflects an incomplete understanding of the problem buys speed, the interest is the time later spent working around an inadequate model, and object modularity is what makes the eventual repayment affordable.
Cunningham, 2009 - Debt Metaphor (video)
Ward Cunningham. "Debt Metaphor." Video, 2009. youtube.com/watch?v=pqeJFYwnkjE.
Seventeen years after coining it, Cunningham recorded a short video correcting the way his metaphor had come to be used. The popular reading, that technical debt means deliberately writing bad code now and cleaning it up later, is not what he meant. The debt is the distance between the team's current understanding of a problem and what the shipped program expresses, and it is repaid by refactoring as understanding improves. That mechanism only works if the code is clean enough to refactor, which means deliberately sloppy code does not create debt so much as destroy the ability to repay it. Anyone quoting the metaphor to justify shortcuts should watch this first.
Lehman, 1980 - Programs, Life Cycles, and Laws of Software Evolution
M. M. Lehman. "Programs, Life Cycles, and Laws of Software Evolution." Proceedings of the IEEE, vol. 68, no. 9, September 1980, pp. 1060-1076. DOI 10.1109/PROC.1980.11805.
Twelve years before the metaphor existed, Lehman explained why software would need one. The paper classifies programs by their relationship to the environment they run in and identifies the sources of evolutionary pressure on them, concluding, in the words of its own abstract, that this "results in a process of never ending maintenance activity." Its laws of program evolution include Continuing Change and Increasing Complexity: a system embedded in the real world must keep changing because deploying it changes the world it models, and its structure degrades as it changes unless deliberate effort is spent preventing that. Every argument on this site for treating debt paydown as permanent rather than exceptional traces back to this idea.
Foote and Yoder, 1997 - Big Ball of Mud
Brian Foote and Joseph Yoder. "Big Ball of Mud." Fourth Conference on Patterns Languages of Programs (PLoP '97), Monticello, Illinois, September 1997; later Chapter 29 of Pattern Languages of Program Design 4, Addison-Wesley, 2000. laputan.org/mud.
The canonical description of sprawling, unstructured architecture, opening with the line "A BIG BALL OF MUD is a casually, even haphazardly, structured system." Its real contribution is the framing: the authors treat the mud ball as a pattern with genuine economic forces behind it rather than as simple incompetence. Time pressure, cost, developer experience, staff turnover, and the invisibility of internal structure reliably produce piecemeal growth, and the resulting architecture is frequently good enough to survive for decades. That is a considerably more useful diagnosis than blaming the previous team.
Theory and Definition
The work of turning a memorable analogy into something you can actually reason about, argue with, and measure.
Kruchten, Nord, and Ozkaya, 2012 - From Metaphor to Theory and Practice
Philippe Kruchten, Robert L. Nord, and Ipek Ozkaya. "Technical Debt: From Metaphor to Theory and Practice." IEEE Software, vol. 29, no. 6, November/December 2012, pp. 18-21. DOI 10.1109/MS.2012.167.
The guest editors' introduction to the IEEE Software special issue that turned technical debt into a research area. The Software Engineering Institute's summary of the paper describes it as considering the metaphor "beyond a 'rhetorical concept.'" The authors argue that by 2012 the term had been stretched to cover nearly every software ill and needed an explicit taxonomy separating visible problems, such as defects and missing features, from the largely invisible internal structure of code, architecture, tests, and documentation. Their practical proposal has aged extremely well: a single unified backlog where debt items compete openly against features, informed by cost and value models rather than by whoever argues loudest.
Dagstuhl Seminar 16162, 2016 - The Consensus Definition
Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman (editors). "Managing Technical Debt in Software Engineering (Dagstuhl Seminar 16162)." Dagstuhl Reports, vol. 6, no. 4, 2016, pp. 110-138. DOI 10.4230/DagRep.6.4.110. Seminar held 17-22 April 2016 at Schloss Dagstuhl.
The closest thing the field has to an agreed definition. The report states that it summarizes "the goals and format of the seminar, results from the breakout groups, a definition for technical debt, a draft conceptual model, and a research road map that culminated from the discussions during the seminar." That definition is quoted more than any other in the technical debt literature:
In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible. Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.
The decisive word is "internal." By bounding technical debt to internal qualities, the seminar deliberately excluded defects, missing features, and performance shortfalls from the term. That is stricter than everyday usage and it is the reason this site distinguishes debt from bugs rather than treating them as one pile. Compare with the working definitions in the glossary.
Fowler, 2009 - Technical Debt Quadrant
Martin Fowler. "Technical Debt Quadrant." Bliki entry, 14 October 2009. martinfowler.com/bliki/TechnicalDebtQuadrant.html.
Not peer-reviewed, and nonetheless one of the most load-bearing pieces of writing in the field. Fowler separates debt taken as a considered trade-off from a mess created by incompetence, noting that "a mess is a reckless debt which results in crippling interest payments or a long period of paying down the principal." He then adds a second axis for debt nobody chose, because design understanding often only arrives after the code is written. "Dividing debt into reckless/prudent and deliberate/inadvertent implies a quadrant." The practical consequence is that prudent deliberate debt is a legitimate delivery lever while reckless debt is a skill or management problem, and the two require completely different responses. See the tech debt quadrant page for how to apply it.
Li, Avgeriou, and Liang, 2015 - A Systematic Mapping Study
Zengyang Li, Paris Avgeriou, and Peng Liang. "A Systematic Mapping Study on Technical Debt and Its Management." Journal of Systems and Software, vol. 101, March 2015, pp. 193-220. DOI 10.1016/j.jss.2014.12.027.
The standard starting point for anyone reading into the field, opening with the framing that technical debt "is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system." Across 94 primary studies the authors produce the widely reused taxonomy of debt types - requirements, architectural, design, code, test, build, documentation, infrastructure, versioning, and defect debt - along with eight management activities. Their conclusion is still broadly true a decade on: identification and measurement are comparatively well studied, while prevention, prioritization, and repayment are thin, and tool support is fragmentary. The taxonomy is the backbone of the types of tech debt page.
Measurement and Management
What practitioners actually do, what the tools actually measure, and where the research says the open problems are.
Ernst et al., 2015 - Measure It? Manage It? Ignore It?
Neil A. Ernst, Stephany Bellomo, Ipek Ozkaya, Robert L. Nord, and Ian Gorton. "Measure It? Manage It? Ignore It? Software Practitioners and Technical Debt." Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015), pp. 50-60. DOI 10.1145/2786805.2786848.
The most important empirical paper on this list, and the one most often ignored by tool vendors. A survey of 1,831 participants, primarily software engineers and architects working on long-lived software-intensive projects, plus follow-up interviews. The headline finding is that "architectural decisions are the most important source of technical debt" - not code smells, not lint violations, not the things static analysis is good at counting. Practitioners recognized and valued the metaphor as a communication device while almost none of them measured debt systematically. If your debt strategy consists of a code quality dashboard, this paper is the argument that you are measuring the wrong layer. See measuring tech debt and architectural decisions.
Avgeriou et al., 2021 - Comparing Technical Debt Measurement Tools
Paris Avgeriou, Davide Taibi, Apostolos Ampatzoglou, Francesca Arcelli Fontana, Terese Besker, Alexander Chatzigeorgiou, Valentina Lenarduzzi, Antonio Martini, Athanasia Moschou, Ilaria Pigazzini, Nyyti Saarimaki, Darius Sas, Saulo S. de Toledo, and Angeliki-Agathi Tsintzira. "An Overview and Comparison of Technical Debt Measurement Tools." IEEE Software, vol. 38, no. 3, 2021, pp. 61-71. DOI 10.1109/MS.2020.3024958.
A fourteen-author comparison of the popular measurement tools and of the empirical evidence for their validity. The opening observation is the one to carry into any tooling decision: "Different tools adopt different terms, metrics, and ways to identify and measure technical debt." The practical consequence is that a remediation-cost figure produced by one tool is not comparable with a figure produced by another, and neither is comparable across codebases with different conventions. If you quote a dollar figure for your debt, name the tool that produced it and treat the number as a trend line rather than a valuation.
Avgeriou et al., 2023 - Technical Debt Management: The Road Ahead
Paris Avgeriou, Ipek Ozkaya, Alexander Chatzigeorgiou, Marcus Ciolkowski, Neil A. Ernst, Ronald J. Koontz, Eltjo Poort, and Forrest Shull. "Technical Debt Management: The Road Ahead for Successful Software Delivery." 2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE), pp. 15-30. DOI 10.1109/ICSE-FOSE59343.2023.00007. Open-access preprint at arXiv 2403.06484.
The current state-of-the-field survey, opening with the line that technical debt is "considered by many to be the 'silent killer' of software projects" and "has undeniably become part of the everyday vocabulary of software engineers." Co-authored by academics and by practitioners from large industrial software organizations, it reviews what industry actually does against what research offers. Two points matter for practitioners: it explicitly notes that debt is sometimes incurred intentionally and beneficially, and it names the genuinely open problems as prioritization, linking debt to business value, and managing debt in long-lived large systems. If you only read one recent paper, read this one.
Machine Learning and AI-Generated Code
The newest and fastest-moving part of the literature, and the part most vulnerable to sloppy citation. Every figure below carries its sample and its date.
Sculley et al., 2015 - Hidden Technical Debt in Machine Learning Systems
D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, and Dan Dennison. "Hidden Technical Debt in Machine Learning Systems." Advances in Neural Information Processing Systems 28 (NIPS 2015), pp. 2503-2511. NeurIPS proceedings.
Almost always referred to by employer rather than by title, which is exactly the citation habit this page exists to correct. Its abstract states that "using the software engineering framework of technical debt, we find it is common to incur massive ongoing maintenance costs in real-world ML systems." The argument is that machine learning systems inherit every maintenance problem of ordinary code and add debt that lives at the system level, invisible to code review: boundary erosion, entanglement, hidden feedback loops, undeclared consumers, data dependencies, configuration issues, and changes in the external world. Because models are trained on data rather than specified, the usual abstraction boundaries leak. The paper predates the current generative wave by most of a decade and describes its failure modes uncomfortably well. See ML and data debt.
Spracklen et al., 2025 - Package Hallucinations by Code-Generating LLMs
Joseph Spracklen, Raveen Wijewickrama, A H M Nazmus Sakib, Anindya Maiti, Bimal Viswanath, and Murtuza Jadliwala. "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs." 34th USENIX Security Symposium, 2025. arXiv 2406.10279.
The peer-reviewed foundation for the supply chain attack now known as slopsquatting. Across 576,000 code samples generated by 16 large language models in two programming languages, the authors report that "the average percentage of hallucinated packages is at least 5.2% for commercial models and 21.7% for open-source models, including a staggering 205,474 unique examples of hallucinated package names." An attacker who registers a frequently hallucinated name gets installs for free. Cite the real figure: popular secondhand versions of this claim understate it by more than an order of magnitude.
Security of AI-Generated Code: Three Distinct Studies
Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions." IEEE Symposium on Security and Privacy, 2022. arXiv 2108.09293. Across 89 security-relevant scenarios producing 1,689 completions, the NYU Tandon authors "found approximately 40% to be vulnerable." This evaluates 2021-era Copilot.
Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh. "Do Users Write More Insecure Code with AI Assistants?" ACM SIGSAC Conference on Computer and Communications Security (CCS '23), 2023. arXiv 2211.03622. A Stanford human-subjects experiment, not a code scan. Participants with access to an AI assistant "wrote significantly less secure code than those without access" and were more confident their code was secure. It supports no percentage-of-vulnerable-code claim at all; cite it for the overconfidence effect only.
Veracode, Inc. "2025 GenAI Code Security Report," 2025. Testing code generated by over 100 large language models across Java, JavaScript, Python, and C#, Veracode reports that "AI-generated code introduced risky security flaws in 45% of tests." This is the most current measured rate available. Veracode is a security vendor and sells remediation tooling, which is worth stating whenever the figure is used. These three sources are frequently merged into a single invented citation; they are separate studies, from separate institutions, measuring separate things.
GitClear, 2025 and 2026 - Code Quality Trend Data
GitClear. "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones," 2025. Analyzing 211 million changed lines from January 2020 through December 2024, GitClear reports that refactoring "sunk from 25% of changed lines in 2021, to less than 10% in 2024," while copy-pasted lines rose from 8.3% to 12.3%.
GitClear. "The Maintainability Gap: AI Code Quality in 2026," 2026. The current edition analyzes 623 million changes from 2023 to 2026 and reports that "block duplication climbed from 40.3 in 2023 to 73.0 year-to-date in 2026 - an 81% increase," with copy-paste rising from 9.4% of changed lines in 2022 to 15.7% in the first half of 2026. GitClear measures code churn, duplication, and refactoring rates from commit data. It has never published a debugging-time metric, and any claim attributing one to GitClear is fabricated. See AI slop and managing AI code quality.
Industry Data and Surveys
Not peer-reviewed, and load-bearing anyway: these are the sources behind the money figures and adoption rates used across this site.
Cost of Poor Software Quality
Consortium for Information and Software Quality (CISQ). "The Cost of Poor Software Quality in the US: A 2022 Report," 2022. CISQ estimates that "the accumulated software Technical Debt (TD) has grown to ~$1.52 trillion" within a total poor-quality cost of at least $2.41 trillion. Use the $1.52 trillion figure whenever the sentence is specifically about technical debt. There is no 2024 edition; only 2020 and 2022 exist.
Developer Time Lost to Maintenance
Stripe, Inc., survey fielded by Harris Poll. "The Developer Coefficient," 2018. Reports that "the average developer spends more than 17 hours a week dealing with maintenance issues, such as debugging and refactoring" out of a 41.1-hour week, of which 13.5 hours is attributed to technical debt. The widely quoted "33% of developer time" is a derived ratio Stripe never printed. Note the date: this is 2018 data, not current.
AI Tool Adoption and Trust
Stack Overflow. "2025 Stack Overflow Developer Survey: AI," 2025. Adoption and confidence are moving in opposite directions: 84% of respondents are using or planning to use AI tools, yet "more developers actively distrust the accuracy of AI tools (46%) than trust it (33%)."
JetBrains s.r.o. "The State of Developer Ecosystem 2025," 2025. A survey of 24,534 developers across 194 countries found "85% of developers regularly use AI tools for coding and development." JetBrains sells developer tooling, so the sample skews toward its own users.
DORA, Google Cloud. "The 2025 DORA Report: State of AI-Assisted Software Development," 2025. Based on nearly 5,000 responses, "90% of survey respondents report using AI at work," while 30% report little or no trust in AI-generated code. Note this samples technology professionals broadly rather than developers exclusively.
Software Delivery Performance Metrics
DORA (Google Cloud). "DORA's software delivery performance metrics," 2026. "DORA has identified five software delivery performance metrics that provide an effective way of measuring the outcomes of the software delivery process." Throughput is measured by change lead time, deployment frequency, and failed deployment recovery time; instability by change fail rate and deployment rework rate. Mean time to recover has been replaced by failed deployment recovery time, so "the four DORA metrics" is only accurate when dated to the original 2014-2023 four keys. The url slug still reads "four-keys" for historical reasons.
Breach Cost and Remediation Time
IBM Corporation, research by Ponemon Institute. "Cost of a Data Breach Report 2025," 2025. "The global average cost of a data breach fell to $4.44 million," while the US average reached a record $10.22 million and the mean time to identify and contain dropped to 241 days. Note the direction of travel: the global number is falling, so any "breach costs keep rising" framing is wrong for it.
Software Supply Chain Attacks
Sonatype, Inc. "2026 State of the Software Supply Chain," 2026. "Sonatype identified more than 454,600 new malicious packages" during 2025, bringing its cumulative blocked total past 1.233 million across npm, PyPI, Maven Central, NuGet, and Hugging Face. Older Sonatype figures of 650% and 742% come from different editions and measure different things; they are not interchangeable.
Accessibility Litigation Volume
UsableNet. "ADA Web Lawsuit Trends for 2026: What 2025 Filings Reveal," 2026. "By the end of 2025, more than 5,000 digital accessibility lawsuits had been filed" in US federal court and the New York and California state courts. UsableNet sells accessibility remediation services; cite the count, not the recommendation.
Sources We Deliberately Do Not Cite
A bibliography is also a statement about what got left out. These are widely repeated in technical debt writing and are not used here, with the reason in each case.
The Standish Group CHAOS Report
The single most-cited source of software project failure statistics, and one whose figures have been challenged in the peer-reviewed literature. In "The Rise and Fall of the Chaos Report Figures," IEEE Software, vol. 27, no. 1, 2010, pp. 30-36, J. L. Eveleens and C. Verhoef applied Standish's own definitions to 5,457 forecasts covering 1,211 real-world projects and concluded that "the Standish figures didn't reflect the reality of the case studies at all." A second problem is scope: CHAOS segments projects by size and never by type, so it reports nothing whatsoever about rebuilds specifically, despite being cited that way constantly. Where a project-failure figure is genuinely needed, cite the critique alongside the original or drop the claim.
The 1:10:100 Defect Cost Curve
The claim that a defect costs ten times more to fix at each successive stage, usually attributed to Barry Boehm, appears constantly in slide decks about the value of early quality work. Research for this page could not trace it to a primary source stating those specific multipliers. The underlying intuition that defects get more expensive the later they are found is uncontroversial; the precise ratios are not sourceable, so they are not quoted here. If you need Boehm, cite "Software Engineering Economics," IEEE Transactions on Software Engineering, vol. SE-10, no. 1, 1984, pp. 4-21, DOI 10.1109/TSE.1984.5010193, and stick to what it actually says.
Merged, Renamed, and Invented Citations
The audit that produced this page found several claims citing publications that do not exist, generic venue names with no paper or author attached, and two separate studies merged into one imaginary joint paper. The most instructive case: a claim that AI tools cause "55% more debugging time," attributed to a company that has never published a debugging metric. The real 55% comes from GitHub's own 2022 study of 95 developers building an HTTP server, in which the Copilot group finished "55% faster" - opposite direction, different measurement, different publisher. That is why the build now hard-fails on known fabricated attribution patterns rather than trusting review.
Flat Dollar Figures With No Publisher
Round, specific-sounding dollar amounts for things like the cost of a developer resignation circulate widely without any traceable origin. Credible published sources express replacement cost as a multiple of salary instead: Gallup's 2019 analysis states that "the cost of replacing an individual employee can range from one-half to two times the employee's annual salary -- and that's a conservative estimate." If you want a dollar range, derive it from a stated salary assumption and show the assumption inline.
Related Resources
History of Tech Debt
The narrative version of this bibliography: how the metaphor spread from one conference report into standard industry vocabulary.
What Is Tech Debt
The working definition, how it differs from the strict academic one, and where the boundary between debt and defects sits.
Measuring Tech Debt
Applying the measurement research in practice, including why tool-reported remediation costs are not comparable across tools.
Why Reduce Tech Debt
Where the industry cost figures on this page get used, with the publisher and year attached to every number.
Software Capitalization
The accounting literature that decides whether debt paydown is an asset or an expense, with the standards and guidance cited in full.
For Executives
Sourced figures assembled for a board conversation, where an unverifiable statistic does the most damage.
Frequently Asked Questions
Ward Cunningham, in an OOPSLA '92 experience report titled The WyCash Portfolio Management System. The paper is about WyCASH+, a Smalltalk cash portfolio management system, and the metaphor occupies a single short paragraph that opens with the line: Shipping first time code is like going into debt. Cunningham returned to the idea in a 2009 video titled Debt Metaphor, in which he corrected the popular misreading of his own words. The debt was never a license to write bad code deliberately; it was the gap between the team's current understanding of a problem and what the shipped program expresses, and repayment depends on the code being clean enough to refactor in the first place.
The most widely used consensus definition comes from Dagstuhl Seminar 16162, Managing Technical Debt in Software Engineering, held in April 2016 and organized by Paris Avgeriou, Philippe Kruchten, Ipek Ozkaya, and Carolyn Seaman. It describes technical debt as a collection of design or implementation constructs that are expedient in the short term but that set up a technical context making future changes more costly or impossible, and it presents that as an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability. The decisive move is that last clause: bounding debt to internal qualities deliberately excludes defects, missing features, and performance shortfalls from the term.
Hidden Technical Debt in Machine Learning Systems, by D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, and Dan Dennison. It was published in Advances in Neural Information Processing Systems 28 at NIPS 2015. It is routinely cited by employer rather than by title, which is a citation failure worth correcting. The paper argues that machine learning systems inherit all the maintenance problems of ordinary code and add debt that lives at the system level: boundary erosion, entanglement, hidden feedback loops, undeclared consumers, data dependencies, configuration issues, and changes in the external world.
Because its figures have been challenged in the peer-reviewed literature. In The Rise and Fall of the Chaos Report Figures, published in IEEE Software in 2010, J. L. Eveleens and C. Verhoef applied Standish's own definitions to 5,457 forecasts covering 1,211 real-world projects and concluded that the Standish figures did not reflect the reality of the case studies at all. Separately, the CHAOS Report segments projects by size and never by type, so it reports nothing whatsoever about rebuilds specifically, despite being cited that way constantly. Where a project-failure statistic is genuinely needed, the honest options are to cite the critique alongside the original or to drop the claim.
Every statistic must resolve to an entry in a machine-checked citation registry that records the publisher, the exact title, the year, an absolute link, the date the source was accessed, and a quotation actually read at that link. A build gate fails the site if any cited identifier does not resolve, if a registry entry is incomplete, or if a known fabricated attribution pattern reappears anywhere in the source. Vendor research is labelled as vendor research. Survey figures carry their sample and their fielding date. If a claim cannot be sourced, the sentence gets deleted rather than quietly reattributed to a different publisher.
Use the contact page and include the page URL, the sentence you are challenging, and the source you believe is correct. Corrections that hold up get applied to the citation registry and therefore to every page that draws on the same entry, which is the main reason the registry exists as a single shared file rather than as footnotes scattered across the site. Errors of attribution are treated as seriously as errors of fact: a real number credited to the wrong publisher, or a figure dated years away from its actual publication, is exactly the failure mode this system was built to catch.
Cite It Properly or Do Not Cite It
A technical debt argument built on an invented statistic loses the moment somebody checks. Use the real papers, name the publisher, give the year, and delete what you cannot verify.