The WyCash Portfolio Management System.¶
Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA ’92 Addendum, 29-30.
Cited by¶
21 citations across 21 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Accumulation
- In organizations and policy, technical debt, regulatory accretion, and institutional memory accumulate from flows of decisions and resist instantaneous correction.
This sourceCoins the technical-debt metaphor, framing accreted shortcuts in a codebase as an accumulated stock that grows from a flow of expedient decisions and resists instantaneous correction.
Supported in partVerified against the work's full text
Cunningham frames unconsolidated shortcut code as accumulating debt that must be repaid by rewrites, supporting only the technical-debt part of the claim.
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.”
- In organizations and policy, technical debt, regulatory accretion, and institutional memory accumulate from flows of decisions and resist instantaneous correction.
- Biofouling
- Software engineering: long-lived codebases accumulate unreferenced functions, dead configurations, deprecated tests, and stale comments, each individually reasonable when added, collectively raising maintenance drag — technical debt as biofouling on the developer-codebase interface.
This sourceIntroduces the "technical debt" metaphor: accreted code that is individually reasonable yet collectively raises maintenance and navigation drag on the developer–codebase interface — occupation cost paid for presence, not activity.
Supported in partVerified against the work's full text
Cunningham's debt metaphor supports the general idea that unconsolidated code, fine when written, accrues a cost that slows development.
“Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable”
- Software engineering: long-lived codebases accumulate unreferenced functions, dead configurations, deprecated tests, and stale comments, each individually reasonable when added, collectively raising maintenance drag — technical debt as biofouling on the developer-codebase interface.
- Clearance Rate
- Toxicological bioaccumulation logic ports to technical-debt accumulation, with the insight that when clearance is slower than input, stock grows linearly with time and cleanup cost is dominated by accumulated stock rather than current input.
This sourceIntroduces the technical-debt metaphor: unremediated shortcuts accrue 'interest,' so debt accumulates when remediation (clearance) lags creation and cleanup cost grows with the accumulated stock.
Supported in partVerified against the work's full text
Cunningham's debt analogy says unrepaid shortcuts accrue interest and can stall an organisation, but it makes no toxicological, linear-growth or cleanup-cost-dominated-by-stock argument.
“Every minute spent on not-quite-right code counts as interest on that debt.”
- Toxicological bioaccumulation logic ports to technical-debt accumulation, with the insight that when clearance is slower than input, stock grows linearly with time and cleanup cost is dominated by accumulated stock rather than current input.
- Exaptation
- Software exaptation is so common that it is frequently the source of technical debt — capability acquired without redesign, at the cost of structures stretched far beyond their original intent.
This sourceACM. Original "technical debt" metaphor: shipping immature, not-quite-right code buys speed now (visible savings) and is repaid with compounding "interest" later, capturing the benefit-now / cost-later temporal-mismatch dynamic.
- Software exaptation is so common that it is frequently the source of technical debt — capability acquired without redesign, at the cost of structures stretched far beyond their original intent.
- Maintenance
- Institutional design matters: if maintenance decisions are made by someone who will bear the cost of failure, maintenance is prioritized; if decisions are separated from responsibility for failure, maintenance is deferred—a temporal-mismatch dynamic Cunningham (1992) named "technical debt" in his founding metaphor for compounding deferred-maintenance costs in software.
This sourceACM. Original "technical debt" metaphor: reframes deferred maintenance as compounding cost incurred today (visible savings) and repaid with interest later (invisible until catastrophic), capturing the prevention-now / benefit-later temporal-mismatch dynamic.
Supported in partVerified against the work's full text
Cunningham likens shipping immature code to taking on debt with interest, supporting the compounding-deferred-cost metaphor but not the institutional-incentive argument.
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.”
- Institutional design matters: if maintenance decisions are made by someone who will bear the cost of failure, maintenance is prioritized; if decisions are separated from responsibility for failure, maintenance is deferred—a temporal-mismatch dynamic Cunningham (1992) named "technical debt" in his founding metaphor for compounding deferred-maintenance costs in software.
- Path Dependence
- Computer science & software engineering: Architectural decisions accumulating technical debt (Cunningham, 1992), API stability requirements creating downstream rigidities, programming language adoption and ecosystem lock-in, database schema decisions binding downstream applications, legacy system dependencies that constrain innovation despite clear modernization benefits.
This sourceACM. Original "technical debt" metaphor: reframes deferred maintenance as compounding cost incurred today (visible savings) and repaid with interest later (invisible until catastrophic), capturing the prevention-now / benefit-later temporal-mismatch dynamic.
Supported in partVerified against the work's full text
Cunningham coins the debt metaphor for unconsolidated code; it does not cover API stability, language or ecosystem lock-in, schema binding or legacy modernization barriers.
“Shipping first time code is like going into debt.”
- Computer science & software engineering: Architectural decisions accumulating technical debt (Cunningham, 1992), API stability requirements creating downstream rigidities, programming language adoption and ecosystem lock-in, database schema decisions binding downstream applications, legacy system dependencies that constrain innovation despite clear modernization benefits.
- Technical Debt
- The compounding with growth is the structural engine: as the codebase grows and a second, then a tenth, customer must be supported, the volume of operations passing through the un-isolated data layer rises, so the integrated cost climbs quasi-exponentially, and at the bankruptcy threshold the interest (the cost of working around the assumption on every change) exceeds the cost of paying down the principal (refactoring to true multi-tenancy).
Supported in partVerified against the work's full text
Cunningham supplies the debt metaphor (not-quite-right code accrues interest until repaid by rewrite) but not the multi-tenancy example, quasi-exponential cost, or bankruptcy threshold.
“Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation”
- The compounding with growth is the structural engine: as the codebase grows and a second, then a tenth, customer must be supported, the volume of operations passing through the un-isolated data layer rises, so the integrated cost climbs quasi-exponentially, and at the bankruptcy threshold the interest (the cost of working around the assumption on every change) exceeds the cost of paying down the principal (refactoring to true multi-tenancy).
Mechanisms¶
- Expansion Debt Review
- It is a direct application of technical debt — the metaphor that shortcuts taken for speed accrue like a loan
This sourceFrames expedient first-time code as debt whose unrepaid interest slows later engineering work.
- It is a direct application of technical debt — the metaphor that shortcuts taken for speed accrue like a loan
- Legacy Health Review Cadence
- It converts "we integrated the legacy" from a finished event into a maintained state, and it is the natural guard against inherited technical debt
This sourceFrames initially acceptable implementation shortcuts as debt whose unrepaid interest accumulates into present maintenance cost.
- It converts "we integrated the legacy" from a finished event into a maintained state, and it is the natural guard against inherited technical debt
- Linked Root-Cause Repair Ticket
- This is technical debt
This sourceTechnical debt permits short-term delivery only if the principal is repaid through consolidation or rewrite; otherwise continuing work accrues interest.
- This is technical debt
- Maintenance Backlog Burn-Down
- … a backlog count is trivially reduced by closing easy items, re-scoping hard ones, or redefining "done," so the number falls while the real substrate keeps decaying — the accounting analog of servicing this month's interest while the principal grows, the way technical debt accrues when only cosmetic fixes are booked.
This sourceIntroduces technical debt as an accounting metaphor in which expedient, not-quite-right code incurs continuing interest until its underlying design is repaid through revision.
- … a backlog count is trivially reduced by closing easy items, re-scoping hard ones, or redefining "done," so the number falls while the real substrate keeps decaying — the accounting analog of servicing this month's interest while the principal grows, the way technical debt accrues when only cosmetic fixes are booked.
- Maintenance Window
- In software the debt being repaid even has a name.
This sourceIntroduces the software-development debt metaphor for expedient code that must later be repaid through rewrite.
- In software the debt being repaid even has a name.
- Rapid Rule-Patch Pipeline
- … failure mode is whack-a-mole patch accumulation hardening into technical debt: the pipeline is so good at shipping local fixes that no one pays down the durable redesign, and the live surface becomes an opaque pile of provisional exceptions that no one fully understands and that collectively fight each other.
This sourceIntroduces technical debt as the future cost of shipping expedient code instead of completing the redesign and refactoring needed to make it right.
- … failure mode is whack-a-mole patch accumulation hardening into technical debt: the pipeline is so good at shipping local fixes that no one pays down the durable redesign, and the live surface becomes an opaque pile of provisional exceptions that no one fully understands and that collectively fight each other.
- Refactoring Cadence
- The recurring rhythm is exactly what makes "pay down debt continuously" real rather than aspirational: small regular payments beat a balloon payment.
This sourceUses the debt analogy to favor prompt rewriting and repeated consolidation during incremental growth over payment up front and in full.
- The recurring rhythm is exactly what makes "pay down debt continuously" real rather than aspirational: small regular payments beat a balloon payment.
- Refactoring Paydown Plan
- It treats accidental complexity as a debt to be retired deliberately, with interest, rather than declared bankrupt in a risky big-bang rewrite.
This sourceIntroduces the debt metaphor for not-quite-right code: it can speed delivery if promptly repaid, while delay accumulates interest and an unconsolidated implementation can eventually halt development.
- It treats accidental complexity as a debt to be retired deliberately, with interest, rather than declared bankrupt in a risky big-bang rewrite.
- Rule-Scoping Patch
- Each patch is locally sensible, but a rule accreting special cases becomes a thicket no one fully understands, and the next self-application often hides between the carve-outs — the accumulation is a form of technical debt that eventually costs more than the redesign it deferred.
This sourceDocuments the accumulation is a form of technical debt that eventually costs more than the redesign it deferred.
- Each patch is locally sensible, but a rule accreting special cases becomes a thicket no one fully understands, and the next self-application often hides between the carve-outs — the accumulation is a form of technical debt that eventually costs more than the redesign it deferred.
- Technical Debt Burndown
- Because debt accrues interest, a burndown that clears slower than new debt arrives is a treadmill — real effort spent while the stock still grows — and the trend chart is what exposes it, if anyone reads it honestly.
This sourceIntroduces the technical-debt metaphor and its accumulating interest: expedient code makes later development progressively more costly until the debt is repaid.
- Because debt accrues interest, a burndown that clears slower than new debt arrives is a treadmill — real effort spent while the stock still grows — and the trend chart is what exposes it, if anyone reads it honestly.
- Technical Debt Paydown Cadence
- Its strength is that it converts an invisible, ever-climbing liability into a serviced balance, keeping a system changeable — the whole value of paying compounding debt down steadily is that steady service is vastly cheaper than the eventual rewrite.
This sourceUses the debt metaphor for expedient code whose accumulating interest impairs change until it is paid down through refactoring.
- Its strength is that it converts an invisible, ever-climbing liability into a serviced balance, keeping a system changeable — the whole value of paying compounding debt down steadily is that steady service is vastly cheaper than the eventual rewrite.
- Technical Debt Register
- The metaphor it rests on is Ward Cunningham's original technical debt
This sourceIntroduces technical debt as the loan-like cost of shipping expedient, not-quite-right code.
- The metaphor it rests on is Ward Cunningham's original technical debt
- Technical Debt Repayment Cycle
- The debt metaphor itself — coined by Ward Cunningham — is what makes the tradeoff legible to non-engineers: shortcuts borrow speed now and repay it, with interest, in slower future change.
This sourceIntroduces Ward Cunningham’s debt metaphor: expedient software borrows speed now and is repaid with interest through slower future change.
- The debt metaphor itself — coined by Ward Cunningham — is what makes the tradeoff legible to non-engineers: shortcuts borrow speed now and repay it, with interest, in slower future change.
- Temporary-Solution Expiry Review
- Improvised configurations accrue technical debt — the accumulating cost of a quick fix left in place — and the expiry review is the forced repayment date that keeps that debt from compounding invisibly.
This sourceUses technical debt to describe the accumulating cost of leaving an expedient, not-quite-right implementation unrepaid.
- Improvised configurations accrue technical debt — the accumulating cost of a quick fix left in place — and the expiry review is the forced repayment date that keeps that debt from compounding invisibly.
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 6 of 21 citations: 6 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 3 other ways.
- http://c2.com/doc/oopsla92.html ×1
- https://c2.com/doc/oopsla92.html ×1
- https://doi.org/10.1145/157710.157715 ×1
Registry ID ref:bb55574305b3 · see in the full table