www.beyondallreason.bar
This is a community project - the official site is: www.beyondallreason.info
Beyond All Reason promotional battle banner — official BAR Media Promokit, beyondallreason.info/promokit.

Origins, credits & effort analysis

Who Really Made Beyond All Reason? A 30-Year Effort Lineage Analysis

Beyond All Reason looks like a standalone game. It isn't. This page traces a 30-year, four-era lineage back to Total Annihilation and the Spring Engine, then applies thirteen independent software-estimation models to work out how much of the game's total effort the current team actually contributed.

The short version

The current BAR team built roughly 5% of what you're playing

≈5%

PERT-weighted estimate of the current (2019–2026) team's net-new architectural contribution, averaged across thirteen independent software-estimation models. The rest — the engine, the netcode, the economy, the balance — was built by three prior teams over the preceding 24 years.

This isn't a dismissal of the current team's work — forking and modernizing a 20-year-old engine, rebuilding the UI, and growing a large volunteer community is real, difficult work. It's a corrective to the perception that BAR was built from scratch since 2019. Jump to the full methodology ↓

Direct answers

Frequently asked questions about Beyond All Reason's origins

Who made Beyond All Reason?

Beyond All Reason (BAR) began in February 2010 as "Balanced Annihilation Reloaded", was abandoned in 2013, and was revived in 2019. It is built by a volunteer team whose lead developer and founder is Beherith (per the official team page). It runs on the Recoil engine, a fork of the Spring RTS engine, and inherits its design from Total Annihilation (Cavedog, 1997).

Is Beyond All Reason based on Total Annihilation?

Yes, in lineage and design. BAR’s streaming Metal/Energy economy, Commander unit and 3D-terrain combat come from Total Annihilation (1997) via the Spring engine and the Balanced Annihilation ruleset. According to Wikipedia, the project began as a replacement for Total Annihilation’s intellectual property and became entirely original.

What engine does Beyond All Reason use?

BAR uses the Recoil engine, an open-source GPL fork and continuation of Spring engine version 105.0. Spring itself began in 2004 as "TA Spring", created by members of the Swedish Yankspankers clan.

How much of Beyond All Reason did the current team build?

Roughly 5%. Across thirteen software-cost-estimation models the current team’s share of total cumulative effort ranges from about 3.6% to 19.2%; the PERT-weighted headline estimate is about 5.2%, and the adjusted models cluster at 3.6% to 10.5%.

How was the 5% figure calculated?

Total effort for each era of the lineage (Total Annihilation, Spring engine, the Balanced Annihilation ecosystem, and BAR) was estimated using COCOMO II, Function Point Analysis, Halstead measures, Putnam/SLIM, Use Case Points, SEER-SEM-style weighting and others. BAR’s share was computed per model, then combined with a three-point PERT weighting: (3.6 + 4×4.7 + 8.7) ÷ 6 ≈ 5.2%.

Is Beyond All Reason free and open source?

Yes. Multiplayer is free and the code is GPL-licensed. In June 2026 BAR signed a publishing deal with Hooded Horse for a paid Premium Edition on Steam with a single-player campaign; the free version and open-source code continue.

What is the relationship between Balanced Annihilation and Beyond All Reason?

Balanced Annihilation (created 2006) is the competitive Spring-engine ruleset (created 2006, following Absolute Annihilation and ÜberHack). BAR began in February 2010 as "Balanced Annihilation Reloaded", an effort to remake it with original assets, so BAR is also a double acronym.

Last reviewed 2026-10-01. Cross-check against the Wikipedia article on Beyond All Reason, the official BAR site and the RecoilEngine repository.

Four eras, one game

The lineage

  1. 1995–1997

    Total Annihilation

    Cavedog Entertainment, led by Chris Taylor

    ~75 person-years

    Invented from a blank page: the streaming Metal/Energy economy, 3D terrain elevation advantage, and the Commander-unit paradigm that every successor in this lineage still runs on. Cavedog Entertainment had roughly 20 staff on the project, per Wikipedia’s Cavedog article.

  2. 2004–present

    The Spring RTS Engine

    Founded by members of the Swedish Yankspankers clan

    ~143 person-years

    A from-scratch 3D engine solving deterministic lockstep networking for thousands of synchronized units — one of the hardest problems in real-time multiplayer software. Grew to roughly 526,000 lines of C++ across two decades of open-source volunteer work. This is the engine BAR’s "Recoil" fork is still built on.

  3. 1998–2019

    The Balance & Modding Ecosystem

    ÜberHack → Absolute Annihilation → Balanced Annihilation

    ~80 person-years

    Twenty-one years of continuous, largely uncredited volunteer labor — thousands of small balance patches, unit reworks, and bug fixes — produced the competitive ruleset that BAR descends from. Most of what a BAR match "feels like" was decided here, not after 2019.

  4. 2019–2026

    Beyond All Reason

    The current BAR team, a volunteer group with five listed founders

    ~45 person-years (gross)

    Revived the 2010-era "Balanced Annihilation Reloaded" project in 2019, forked Spring into the Recoil engine, modernized the rendering pipeline and UI, and built the Teiserver lobby/matchmaking infrastructure. Real, valuable work — but built entirely on the three eras above.

Full dated source list in Appendix A below.

Twelve models, one question

What share of total effort is the current team's?

Each bar is an independently computed result from a standard software-cost-estimation methodology (full workings in Section: Full Methodology). Models that discount for code reuse, inherited complexity, and 20+ years of invisible defect-removal labor — the methodologically correct way to measure "who architected this" — are marked adjusted. Naive models that just count hours or raw lines are marked unadjusted and consistently run higher.

PERT-weighted central estimate5.2%
  • COCOMO II Reuse Modelunadjusted

    upper bound — most generous plausible reuse assumptions

  • FTE Modeling (raw hours)unadjusted

    ceiling figure — counts hours only, no complexity or reuse adjustment

  • COQUALMO (Defect Removal)unadjusted
  • Putnam / SLIM (vs. TA baseline)unadjusted

    compares BAR only to TA’s crunch-inflated effort, not the full lineage

  • Halstead Complexity Measuresunadjusted
  • SEER-SEM Complexity Weightingadjusted
  • Function Point Analysisadjusted
  • Story Points / Delphi Consensusunadjusted

    softest, most subjective model — sanity check only

  • SLOC / KLOC Extrapolationadjusted
  • Use Case Points (corrected)adjusted

    original naive run produced an outlier 45%, discarded — see Methodology 10

  • COCOMO IIadjusted
  • Cyclomatic Complexity Deflationadjusted

Range across all twelve retained models: 3.6%–19.2% (one additional outlier run of 45% under Use Case Points was investigated, found to rest on a flawed weighting, corrected, and is not plotted — see Methodology 10). The complexity/reuse-adjusted subset alone clusters between 3.6% and 8.7%, median ≈6%.

Show your work

Full methodology — thirteen independent models

Every model below was researched and computed independently against real, cited sources. Where a precise figure could not be verified, that is stated explicitly rather than presented as fact. Expand any section for the full reasoning, arithmetic, and citations.

1. FTE (Full-Time Equivalent) Modeling — 16.9% ceiling figure

Converts documented team sizes and durations into person-years, with no adjustment for complexity or reuse: ~20 Cavedog staff on Total Annihilation (33 PY, applying an overtime-multiplier assumption that is not independently sourced), Spring's OpenHub-derived 143 PY, an estimated 8-FTE-equivalent volunteer core sustaining the 21-year modding ecosystem (168 PY), and BAR scaling from 2.5 to ~12 FTE across 2019–2026 (70 PY).

70 ÷ (33 + 143 + 168 + 70) = 70 ÷ 414 ≈ 16.9%

This is the ceiling figure in the report: it counts hours, not architectural novelty. Every other model exists to discount it.

Sources: Wikipedia, "Cavedog Entertainment," "Chris Taylor (video game designer)," "Beyond All Reason"; Game Developer magazine, "Playing Catch Up: Gas Powered Games' Chris Taylor"; OpenHub.net, Spring RTS Engine project page; GitHub (spring/spring, Balanced-Annihilation); beyondallreason.info Team & Development pages.

2. COCOMO II (Constructive Cost Model) — 4.7%

Basic/Organic-mode formula: Effort (PM) = 2.4 × (KLOC)^1.05. Applied to Spring's ~526 KLOC codebase (≈110 PY first-principles, cross-checked against OpenHub's own published 143 PY, adopted as the working baseline since it better reflects distributed open-source overhead). Applied to BAR's estimated net-new/modified delta of ~70 KLOC across the Recoil rendering-pipeline fork and new Lua UI: 2.4 × 70^1.05 ≈ 175 person-months ≈ 14.6 PY.

14.6 ÷ (75 + 143 + 80 + 14.6) = 14.6 ÷ 312.6 ≈ 4.7%

Sensitivity: at 50 KLOC net-new, BAR ≈ 3.2%; at 90 KLOC, BAR ≈ 5.8%. Robust to reasonable uncertainty in the KLOC estimate — stays in the low single digits either way.

Sources: Boehm, Software Engineering Economics (1981); USC Center for Systems and Software Engineering, COCOMO II Model Definition Manual v2.1; OpenHub.net; GitHub (spring/spring, beyond-all-reason/RecoilEngine).

3. COCOMO II Non-Linear Reuse Model — 19.2% upper bound

Isolates the effort of adapting legacy code via AAF = 0.4·DM + 0.3·CM + 0.3·IM, then ESLOC = ASLOC × (1 − AT/100) × AAM. Using generous modification estimates for a Recoil-scale fork (Design Modified 35%, Code Modified 42%, Integration Modified 28%) against Spring's ~526 KSLOC base: AAF = 35.0 → AAM ≈ 0.465 → ESLOC ≈ 244.6 KSLOC → Effort ≈ 71 PY.

71 ÷ (75 + 143 + 80 + 71) = 71 ÷ 369 ≈ 19.2%

This is the highest reuse-adjusted result in the report, because its modification-percentage inputs (35–42%) are considerably more generous than the git-diff evidence in Methodology 8 supports. Kept transparently as the model's upper bound — different reasonable "how modified is modified" assumptions can move this estimate by 4–20×.

Sources: Boehm et al., Software Cost Estimation with COCOMO II (Prentice Hall, 2000); OpenHub calibration data; GitHub (RecoilEngine PRs/discussions).

4. SEER-SEM Parametric Weighting — 10.5%

Weights effort by functional-complexity category rather than treating all code equally — backend systems work (physics, deterministic networking, pathfinding) at 2.5–4.0× the effort-intensity of frontend/UI/shader work (a range drawn from general software-engineering literature on systems vs. interface programming costs), applied here at a 3.5× midpoint. Phases assessed for backend/frontend composition (TA ~95% backend; Spring ~75% backend; the ecosystem ~20% backend; BAR ~42% backend, majority UI/rendering/PBR polish) and recomputed as complexity-weighted person-years (877.4 CPY total across the lineage).

BAR share ≈ 10.5% (sensitivity range 9.8–11.2%)

Sits in the middle of all results — a useful check against models that assume BAR's contribution is entirely frontend, since Recoil's fork does touch some backend rendering/simulation code.

Sources: Galorath & Evans, Software Sizing, Estimation, and Risk Management (Auerbach, 2006); Sommerville, Software Engineering, 10th ed. (2015); McConnell, Software Estimation: Demystifying the Black Art (2006).

5. The Putnam Model (SLIM) & Schedule Compression — 11.4% vs. TA only

Putnam's model ties effort to schedule via a strongly nonlinear relationship (E ∝ K·T^3.6); Brooks' Mythical Man-Month documents the same effect from the coordination-overhead side. Total Annihilation's ~20-month, reportedly 7-day/12-hour cycle represents 55–60% schedule compression versus a "normal" 3–4 year RTS cycle. Applying a conservative 1.4× effort-inflation multiplier: TA's effective effort rises from 75 PY to ≈105 PY. BAR's 7-year volunteer-paced schedule shows no comparable compression (1.0×), but only ~30% of its 45 PY gross is judged genuinely novel rather than porting/rebalancing prior work (≈13.5 PY effective).

13.5 ÷ (105 + 13.5) ≈ 11.4%

This model deliberately isolates TA as the comparison case to show how badly raw-hours math understates crunch-era effort. Folded into the full four-phase total instead of compared to TA alone, BAR's share falls further, into the mid-single digits, consistent with the other reuse-adjusted models.

Sources: Putnam, "A General Empirical Solution to the Macro Software Sizing and Estimating Problem," IEEE TSE 4(4), 1978; Brooks, The Mythical Man-Month (1975); PC Gamer, "The Making of Total Annihilation"; Game Developer magazine, Chris Taylor interview.

6. Cyclomatic Complexity Deflation — 3.6% lowest estimate

McCabe's cyclomatic complexity (M = E − N + 2P) measures independent execution paths through code — a proxy for verification/implementation effort. Deterministic lockstep multiplayer networking (Spring, Phase 2) is widely regarded in game-engine literature as among the highest-complexity domains in an engine, since every path must produce bit-identical results across machines despite floating-point nondeterminism, packet loss, and latency. BAR's Phase 4 work concentrates in Lua UI widgets and rendering/shader code — substantially simpler control flow. Applying a conservative, literature-informed 4× complexity-deflation ratio to BAR's gross 45 PY: 45 ÷ 4 = 11.25 PY.

11.25 ÷ (75 + 143 + 80 + 11.25) = 11.25 ÷ 309.25 ≈ 3.6%

Sources: McCabe, "A Complexity Measure," IEEE TSE SE-2(4), 1976; Gregory, Game Engine Architecture, 3rd ed. (2019); Rosenberg & Hyatt, Journal of Systems and Software 38(2), 1997.

7. Halstead Complexity Measures — 11.1%

Halstead Volume (V = N × log₂(n₁+n₂)) estimates a codebase's "algorithmic substance" from operator/operand vocabulary. No published Halstead analysis of the Spring/Recoil codebases exists — stated here as an explicit limitation rather than glossed over. Extrapolating token density from Spring's ~526 KLOC (≈17.7M bits estimated Volume) against BAR's ~120 KLOC of net contribution, discounted for a higher proportion of repetitive boilerplate versus novel algorithmic logic (≈2.2M bits estimated Volume).

2.2 ÷ (17.7 + 2.2) ≈ 11.1%

Notably close to BAR's raw, undiscounted SLOC ratio (≈18.6% of combined KLOC) — the gap is entirely the reasoned (not measured) novelty-density discount.

Sources: Halstead, Elements of Software Science (1977); OpenHub.net; GitHub (spring/spring, beyond-all-reason/RecoilEngine); Verifysoft Halstead Metrics documentation.

8. SLOC/KLOC Historical Extrapolation — 6.7% range 6.7–10.3%

Using repository structure and commit-history analysis: ~526,000 SLOC for Spring (cross-validated against its COCOMO-implied 143 PY); a proxy estimate of 250,000–350,000 SLOC for TA's original 1990s codebase (no primary figure survives); ~60,000–85,000 net-new/modified lines for BAR/Recoil. Raw, undiscounted share: 85,000 ÷ ~825,000 ≈ 10.3%.

Code-churn literature establishes that 30–40% of any fork "diff" is identifier renaming, reformatting, and API updates rather than genuinely new logic. Applying a 35% novelty discount: 85,000 × 0.65 = 55,250 true net-new lines.

55,250 ÷ 825,000 ≈ 6.7%

Sources: OpenHub.net; GitHub (spring/spring, beyond-all-reason/RecoilEngine); Munson & Elbaum, "Code Churn: A Measure for Estimating the Impact of Code Change," IEEE TSE 24(11), 1998.

9. Function Point Analysis (FPA) — 8.7%

Function Points measure functional size from a user's perspective — inputs, outputs, inquiries, logical files — independent of implementation language. The core simulation (unit movement, weapon/damage calculation, the streaming Metal/Energy economy, terrain/pathfinding, fog of war, multiplayer sync — the functional heart of any RTS, established by TA and Spring) accounts for an estimated 215 function points. BAR-specific additions (Teiserver matchmaking, modernized UI, replay/spectator tooling, Discord linking, engine polish) account for an estimated 23; the intervening modding ecosystem contributes ~25.

23 ÷ (215 + 25 + 23) = 23 ÷ 263 ≈ 8.7%

Caveat: FPA measures functional scope, not effort — a small function-point count can still represent meaningful engineering hours, which is part of why this model runs slightly higher than the pure complexity-weighted ones.

Sources: Albrecht, "Measuring Application Development Productivity" (IBM, 1979); IFPUG, Function Point Counting Practices Manual, Release 4.3.1 (2010).

10. Use Case Points (UCP) — corrected to 4–8% outlier discarded

Karner's Use Case Points method sizes software by actor/use-case complexity. An independently-run first pass at this methodology produced a 45% BAR share — inconsistent with every other model in this report by roughly an order of magnitude. On review, that run rested on an ad hoc "person-days per use case" weighting rather than Karner's actual actor/transaction-complexity method, and it double-counted refinement labor already captured under COQUALMO (Methodology 11). It is disclosed here rather than quietly dropped.

A corrected count, following Karner's original method and counting only genuinely new use cases (matchmaking/ranked play, onboarding, the replay browser, dynamic graphics settings) against the full lineage's ~240+ use-case inventory — of which the large majority trace to 2006-era Balanced Annihilation — yields:

Corrected estimate: 4–8% (wide, low-confidence band, not a false-precision point figure)

Sources: Karner, "Resource Estimation for Objectory Projects" (1993); Kroll & Kruchten (2003); Booch, Rumbaugh & Jacobson (1999).

11. COQUALMO (Defect-Removal Effort) — 13.7%

Extends COCOMO II to separately estimate defect-introduction and defect-removal effort — a lifecycle-cost category easy to overlook when only "new features" are counted. Boehm & Basili's widely cited finding that 40–60%+ of lifecycle effort in long-lived software goes to maintenance/defect-repair is directly relevant to the 21-year modding ecosystem, which was overwhelmingly iterative balance patches and bug fixes rather than net-new features. Estimated defect-removal shares: TA 5 PY (greenfield, minimal legacy debt), Spring 35 PY, the Ecosystem 60 PY (of its 80 PY baseline), BAR 18 PY (of its 45 PY baseline, younger codebase, higher feature velocity).

18 ÷ (5 + 35 + 60 + 18) = 18 ÷ 118 ≈ 15.3% of defect-removal effort; 63 ÷ 461 ≈ 13.7% of combined effort

Deliberately makes the 20-year volunteer bug-fixing/balance-patching labor visible and countable — which raises the Ecosystem phase's effective effort substantially and correspondingly shrinks every other phase's relative share, even though BAR's own percentage under this specific accounting runs higher than the complexity-deflation models, since COQUALMO does not discount BAR's defect-removal labor by complexity the way Methodology 6 does.

Sources: Chulani & Boehm, "Modeling Software Defect Introduction and Removal: COQUALMO," USC-CSE (1999); Boehm & Basili, "Software Defect Reduction Top 10 List," IEEE Computer 34(1), 2001; GitHub (Balanced-Annihilation commit history).

12–13. Agile Story Points & Delphi Expert Consensus — 6–10% softest model, sanity check only

Story points measure relative effort; retroactively applying them to pre-Agile, pre-repository-era work is an analogy, not a measurement, and is flagged as such. Using proxy signals (commit volume, changelog density, contributor-count growth, release cadence) rather than fabricated absolute totals, a relative-scope allocation across the four phases (TA ≈100 units; Spring's 20+ years of continuous maintenance ≈250–300 units; the ecosystem ≈80–100 units; BAR ≈40–60 units) yields a BAR share of roughly 8–12%.

A proper Delphi study requires a live, iterative expert survey, which could not be conducted; publicly available community statements were used as a proxy instead. Explicit comparative statements proved sparse — the observable pattern is that BAR's own community consistently describes it as a "revival" and "continuation" of Spring/Balanced Annihilation, not a reinvention, supporting a conservative expert-judgment estimate of 5–8%.

Combined estimate: 6–10%, explicitly the widest-uncertainty band in this report

Sources: Cohn, Agile Estimating and Planning (2005); Dalkey & Helmer, "An Experimental Application of the Delphi Method to the Use of Experts," Management Science 9(3), 1963; beyondallreason.info Team page and news archive; GitHub (spring/spring, Balanced-Annihilation).

Reading the spread

Models that treat all labor-hours as equivalent produce high BAR shares (10–19%); models that explicitly account for inherited architectural complexity, code reuse, and 20+ years of invisible defect-removal labor converge on low-single-digit shares (3.6–8.7%). This isn't a contradiction — it's the expected signature of a genuinely derivative project. A line of Lua UI code and a line of deterministic-networking C++ cost the same to store in a repository but are not remotely equivalent in engineering difficulty, and every model that makes that distinction explicit pulls BAR's share down.

A PERT-weighted estimate using the complexity-adjusted cluster's minimum (3.6%, Cyclomatic Deflation), maximum (8.7%, Function Points), and most directly-grounded likely value (4.7%, COCOMO II):

PERT = (3.6 + 4×4.7 + 8.7) ÷ 6 = 31.1 ÷ 6 ≈ 5.2%

Appendix A

Verified historical timeline

Compiled from primary and secondary sources — official wikis, GitHub repositories, contemporary press, and developer statements. Claims that could not be independently verified are marked as such rather than presented as fact.

Show the full dated timeline (with sources)
DateEventSource
1995Cavedog Entertainment founded as a division of Humongous EntertainmentWikipedia: Cavedog Entertainment
1995–97Total Annihilation developed under lead designer Chris Taylor; team of ~20 staffWikipedia: Total Annihilation; Wikipedia: Chris Taylor
Sep 27, 1997Total Annihilation released in North America — first RTS with 3D terrain elevation, a streaming Metal/Energy economy, and the Commander-unit paradigmWikipedia: Total Annihilation
Jan 1996 – Mar 1998Chris Taylor works at Cavedog as designer and project leader on Total AnnihilationWikipedia: Chris Taylor
Apr 29, 1998The Core Contingency expansion releasedWikipedia: The Core Contingency
Jul 20, 1998Battle Tactics expansion releasedWikipedia: Battle Tactics
1998–2002ÜberHack mod created (credited to BraveSirRobin), the first major competitive-balance rework of TATotal Annihilation Wiki: Balanced Annihilation
Aug 17, 2004The Swedish Yankspankers publicly show screenshots and video of "TA Spring," a 3D RTS engine that reads Total Annihilation data formats directlySlashdot (Aug 17, 2004)
2000Cavedog Entertainment ceases operationsWikipedia: Cavedog Entertainment
2002–2006Absolute Annihilation mod developed (credited to Caydr), standardizing unit balance furtherTotal Annihilation Wiki: Balanced Annihilation
2004–2005The "Spring" ("TA Spring") engine project is developed by members of the Swedish Yankspankers clan and released as open source (GPL) in April 2005SpringRTS Wiki: History; Wikipedia: Beyond All Reason
2006Balanced Annihilation created — the definitive competitive ruleset on Spring, and the ancestor BAR descends fromGitHub: Balanced-Annihilation-106; TA Wiki
Apr 2005Spring is released as open source under the GPLSpringRTS Wiki: History; spring/spring
2005–2026Spring Engine matures; Open Hub’s COCOMO-based analysis estimates ~143 person-years of cumulative effort from its first commit in May 2005 (the ~526,000-line figure is Open Hub’s at time of analysis and was not independently re-counted)Open Hub: Spring RTS Engine
Feb 2010 – 2013Project begins as "Balanced Annihilation Reloaded," an effort to remake Balanced Annihilation with original assets; first artwork 2010; abandoned 2013Wikipedia: Beyond All Reason; TA Wiki: Beyond All Reason
2019Project revived as Beyond All Reason by a small core team (exact "2.5 developers" phrasing could not be independently source-verified)Wikipedia: Beyond All Reason; BAR team page
By Nov 2021The Recoil engine exists as a fork of Spring 105 (BAR105 branch); the earliest dated changelog discussion is Nov 4, 2021RecoilEngine Discussion #171; RecoilEngine
Feb 15, 2026BAR announces 70,000 Discord members, nearly double its previous 40,000 milestoneBAR news: 70K Discord members
Jun 16, 2026Publisher Hooded Horse signs a publishing deal for BAR’s Steam release; the game and code remain open source and freeBAR announcement; GamingOnLinux; Wikipedia: Hooded Horse

Appendix B

Full bibliography: 161 sources with full citations and links

Every entry gives author, year, title, publisher or journal, identifier (DOI or ISBN where one exists) and the full URL. Links were retrieved and checked on 2026-09-18. Sources are grouped by role in the analysis; Wikipedia entries are overview references, and primary or peer-reviewed sources are listed separately.

Total Annihilation and Cavedog (1995–2000) (15)

  1. Wikipedia contributors. Total Annihilation. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Total_Annihilation Accessed 2026-09-18. Release date (NA) September 27, 1997; Spring engine origin; sales figures.
  2. Wikipedia contributors. Total Annihilation: The Core Contingency. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Total_Annihilation:_The_Core_Contingency Accessed 2026-09-18.
  3. Wikipedia contributors. Total Annihilation: Battle Tactics. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Total_Annihilation:_Battle_Tactics Accessed 2026-09-18.
  4. Wikipedia contributors. Cavedog Entertainment. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Cavedog_Entertainment Accessed 2026-09-18. Founded 1995 under Humongous Entertainment; ~20 staff on Total Annihilation; closed February 2000.
  5. Wikipedia contributors. Chris Taylor (video game designer). Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Chris_Taylor_(video_game_designer) Accessed 2026-09-18. Joined Cavedog January 1996 as designer and project leader; left March 1998.
  6. Wikipedia contributors. Humongous Entertainment. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Humongous_Entertainment Accessed 2026-09-18.
  7. Wikipedia contributors. GT Interactive. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/GT_Interactive Accessed 2026-09-18.
  8. Wikipedia contributors. Jeremy Soule. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Jeremy_Soule Accessed 2026-09-18.
  9. Wikipedia contributors. Ron Gilbert. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Ron_Gilbert Accessed 2026-09-18.
  10. Wikipedia contributors. Gas Powered Games. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Gas_Powered_Games Accessed 2026-09-18.
  11. Wikipedia contributors. Supreme Commander (video game). Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Supreme_Commander_(video_game) Accessed 2026-09-18.
  12. Wikipedia contributors. Real-time strategy. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Real-time_strategy Accessed 2026-09-18.
  13. Gestalt (2000-02-28). Let Sleeping Dogs Die. Eurogamer. https://www.eurogamer.net/articles/cavedog_rip Accessed 2026-09-18.
  14. (2000). Cavedog Entertainment official website (archived snapshot, 2000). Internet Archive Wayback Machine. Internet Archive. https://web.archive.org/web/2000/http://www.cavedog.com/ Accessed 2026-09-18.
  15. . Chris Taylor (Person). Giant Bomb Video Game Wiki. Fandom, Inc.. https://www.giantbomb.com/chris-taylor/3040-7137/ Accessed 2026-09-18.

Spring, Recoil and the open-source engine layer (29)

  1. . Spring RTS Engine (official project site). springrts.com. Spring RTS project. https://springrts.com/ Accessed 2026-09-18.
  2. . History. Spring RTS Engine Wiki. Spring RTS project. https://springrts.com/wiki/History Accessed 2026-09-18.
  3. . Spring RTS Engine Wiki: Main Page. Spring RTS Engine Wiki. Spring RTS project. https://springrts.com/wiki/Main_Page Accessed 2026-09-18.
  4. . spring/spring: A powerful free cross-platform RTS game engine. GitHub. Spring RTS project. https://github.com/spring/spring Accessed 2026-09-18.
  5. (2004-08-17). Hobbyist "Spring" RTS Engine Takes Shape. Slashdot. https://games.slashdot.org/story/04/08/17/0334203/hobbyist-spring-rts-engine-takes-shape Accessed 2026-09-18. First public showing of TA Spring by the Swedish Yankspankers.
  6. . The Spring RTS Engine Open Source Project on Open Hub. Open Hub (Black Duck). https://openhub.net/p/springrts Accessed 2026-09-18. COCOMO-based estimate of ~143 person-years; first commit May 2005.
  7. . Spring project. Total Annihilation Wiki (Fandom). Fandom, Inc.. https://totalannihilation.fandom.com/wiki/Spring_project Accessed 2026-09-18.
  8. . Spring. Libregamewiki. https://libregamewiki.org/Spring Accessed 2026-09-18.
  9. . Spring: RTS game engine. LinuxLinks. https://www.linuxlinks.com/spring-2/ Accessed 2026-09-18.
  10. . Spring RTS Engine: download and project page. SourceForge. Slashdot Media. https://sourceforge.net/projects/springrts/ Accessed 2026-09-18.
  11. . Spring:1944, a free open-source WWII RTS built on the Spring engine. spring1944.github.io. https://spring1944.github.io/ Accessed 2026-09-18.
  12. Wikipedia contributors. Spring Engine (Spanish edition). Wikipedia, la enciclopedia libre. Wikimedia Foundation. https://es.wikipedia.org/wiki/Spring_Engine Accessed 2026-09-18.
  13. . Recoil: Design large scale RTS games (official site). recoilengine.org. https://recoilengine.org/ Accessed 2026-09-18.
  14. . Recoil Engine documentation. recoilengine.org. https://recoilengine.org/docs/ Accessed 2026-09-18.
  15. . beyond-all-reason/RecoilEngine: A powerful free cross-platform RTS game engine. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/RecoilEngine Accessed 2026-09-18. Describes itself as a fork and continuation of Spring RTS engine version 105.0.
  16. (2021-11-04). WIP changelog since the fork (Discussion #171). GitHub: beyond-all-reason/RecoilEngine. Beyond All Reason. https://github.com/beyond-all-reason/RecoilEngine/discussions/171 Accessed 2026-09-18. Earliest dated changelog since the fork; forked from the BAR105 branch.
  17. . RecoilEngine releases. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/RecoilEngine/releases Accessed 2026-09-18.
  18. . RecoilEngine LICENSE. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/RecoilEngine/blob/master/LICENSE Accessed 2026-09-18.
  19. Free Software Foundation (1991). GNU General Public License, version 2. GNU Operating System. Free Software Foundation. https://www.gnu.org/licenses/old-licenses/gpl-2.0.html Accessed 2026-09-18.
  20. Free Software Foundation (2007). GNU General Public License, version 3. GNU Operating System. Free Software Foundation. https://www.gnu.org/licenses/gpl-3.0.html Accessed 2026-09-18.
  21. Wikipedia contributors. GNU General Public License. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/GNU_General_Public_License Accessed 2026-09-18.
  22. Wikipedia contributors. Lua. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Lua Accessed 2026-09-18.
  23. . The Programming Language Lua. lua.org. PUC-Rio. https://www.lua.org/ Accessed 2026-09-18.
  24. Wikipedia contributors. OpenGL. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/OpenGL Accessed 2026-09-18.
  25. Wikipedia contributors. Lockstep (computing). Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Lockstep_(computing) Accessed 2026-09-18.
  26. Wikipedia contributors. Netcode. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Netcode Accessed 2026-09-18.
  27. Wikipedia contributors. Game engine. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Game_engine Accessed 2026-09-18.
  28. Wikipedia contributors. Fork (software development). Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Fork_(software_development) Accessed 2026-09-18.
  29. Wikipedia contributors. Multiplayer video game. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Multiplayer_video_game Accessed 2026-09-18.

Balanced Annihilation, Beyond All Reason and the 2019–2026 era (36)

  1. Wikipedia contributors. Beyond All Reason. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Beyond_All_Reason Accessed 2026-09-18. First artwork 2010; abandoned 2013; revived 2019; Recoil engine; Hooded Horse deal June 2026.
  2. . Beyond All Reason RTS (official website). beyondallreason.info. https://www.beyondallreason.info/ Accessed 2026-09-18.
  3. . Team. Beyond All Reason RTS. Beyond All Reason. https://www.beyondallreason.info/team Accessed 2026-09-18.
  4. . Beherith: Lead Developer. Beyond All Reason RTS. Beyond All Reason. https://www.beyondallreason.info/team/beherith Accessed 2026-09-18. Describes Beherith as founder and lead developer.
  5. . News. Beyond All Reason RTS. Beyond All Reason. https://www.beyondallreason.info/news Accessed 2026-09-18.
  6. . Download Beyond All Reason. Beyond All Reason RTS. Beyond All Reason. https://www.beyondallreason.info/download Accessed 2026-09-18.
  7. (2026-06-16). Beyond All Reason and Hooded Horse: a new chapter. Beyond All Reason RTS News. Beyond All Reason. https://www.beyondallreason.info/news/beyond-all-reason-and-hooded-horse Accessed 2026-09-18.
  8. (2026-02-15). Exclusive Lore Drop and Massive Games to Celebrate 70K Discord Members!. Beyond All Reason RTS News. Beyond All Reason. https://www.beyondallreason.info/news/70000-discord-members-lore-drop Accessed 2026-09-18.
  9. (2026-06). Open source RTS game Beyond All Reason signs publishing deal with Hooded Horse. GamingOnLinux. https://www.gamingonlinux.com/2026/06/open-source-rts-game-beyond-all-reason-signs-publishing-deal-with-hooded-horse/ Accessed 2026-09-18.
  10. (2026). Beyond All Reason RTS signs publishing deal with Hooded Horse. Delimiter Online. https://delimiter.online/blog/beyond-all-reason-publishing-deal/ Accessed 2026-09-18.
  11. (2026). Beyond All Reason (BAR): Open Source Powered RTS will get Premium Steam Release published by Hooded Horse. ResetEra forum. https://www.resetera.com/threads/beyond-all-reason-bar-open-source-powered-rts-will-get-premium-steam-release-published-by-hooded-horse.1554460/ Accessed 2026-09-18. Community discussion thread.
  12. (2026). Beyond All Reason RTS (@BAR_RTS) announcement post. X (formerly Twitter). https://x.com/BAR_RTS/status/2066966225670869324 Accessed 2026-09-18.
  13. . beyond-all-reason: GitHub organization. GitHub. Beyond All Reason. https://github.com/beyond-all-reason Accessed 2026-09-18.
  14. . beyond-all-reason/Beyond-All-Reason: main game repository. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/Beyond-All-Reason Accessed 2026-09-18.
  15. . Beyond All Reason LICENSE.md. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/Beyond-All-Reason/blob/master/LICENSE.md Accessed 2026-09-18.
  16. . Beyond All Reason license_general.txt. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/Beyond-All-Reason/blob/master/license_general.txt Accessed 2026-09-18.
  17. . beyond-all-reason/teiserver: lobby and matchmaking server. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/teiserver Accessed 2026-09-18.
  18. . beyond-all-reason/BYAR-Chobby: game lobby client. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/BYAR-Chobby Accessed 2026-09-18.
  19. . BYAR-Chobby releases. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/BYAR-Chobby/releases Accessed 2026-09-18.
  20. . beyond-all-reason/spads_config_bar: SPADS autohost configuration. GitHub. Beyond All Reason. https://github.com/beyond-all-reason/spads_config_bar Accessed 2026-09-18.
  21. . Balanced-Annihilation/Balanced-Annihilation-106: Spring-106 branch. GitHub. Balanced Annihilation project. https://github.com/Balanced-Annihilation/Balanced-Annihilation-106 Accessed 2026-09-18. Created in 2006; a modding-community RTS ruleset.
  22. . Balanced-Annihilation (GitLab repository). GitLab. Balanced Annihilation project. https://gitlab.com/balanced-annihilation/Balanced-Annihilation Accessed 2026-09-18.
  23. . Balanced Annihilation. Total Annihilation Wiki (Fandom). Fandom, Inc.. https://totalannihilation.fandom.com/wiki/Balanced_Annihilation Accessed 2026-09-18. Lineage: ÜberHack (1998–2002) to Absolute Annihilation (2002–2006) to Balanced Annihilation (2006).
  24. . Software: Beyond All Reason (video game). HandWiki. HandWiki. https://handwiki.org/wiki/Software:Beyond_All_Reason_(video_game) Accessed 2026-09-18.
  25. . Beyond All Reason. Total Annihilation Wiki (Fandom). Fandom, Inc.. https://totalannihilation.fandom.com/wiki/Beyond_All_Reason Accessed 2026-09-18.
  26. . r/beyondallreason. Reddit. Reddit, Inc.. https://www.reddit.com/r/beyondallreason/ Accessed 2026-09-18.
  27. . Beyond All Reason | BAR: official Discord server. Discord. Discord Inc.. https://discord.com/invite/beyond-all-reason Accessed 2026-09-18.
  28. Wikipedia contributors. Hooded Horse. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Hooded_Horse Accessed 2026-09-18.
  29. Wikipedia contributors. Manor Lords. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Manor_Lords Accessed 2026-09-18.
  30. Wikipedia contributors. Terra Invicta. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Terra_Invicta Accessed 2026-09-18.
  31. Wikipedia contributors. Zero-K. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Zero-K Accessed 2026-09-18. Another RTS derived from the Spring-engine ecosystem.
  32. Wikipedia contributors. Steam (service). Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Steam_(service) Accessed 2026-09-18.
  33. Wikipedia contributors. Discord. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Discord Accessed 2026-09-18.
  34. Wikipedia contributors. Mod (video games). Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Mod_(video_games) Accessed 2026-09-18.
  35. Wikipedia contributors. Open-source video game. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Open-source_video_game Accessed 2026-09-18.
  36. Wikipedia contributors. List of open-source video games. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/List_of_open-source_video_games Accessed 2026-09-18.

Estimation methods: reference overviews (39)

  1. Wikipedia contributors. COCOMO. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/COCOMO Accessed 2026-09-18.
  2. Wikipedia contributors. Function point. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Function_point Accessed 2026-09-18.
  3. Wikipedia contributors. Halstead complexity measures. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Halstead_complexity_measures Accessed 2026-09-18.
  4. Wikipedia contributors. Cyclomatic complexity. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Cyclomatic_complexity Accessed 2026-09-18.
  5. Wikipedia contributors. Putnam model. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Putnam_model Accessed 2026-09-18.
  6. Wikipedia contributors. Use case points. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Use_case_points Accessed 2026-09-18.
  7. Wikipedia contributors. Delphi method. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Delphi_method Accessed 2026-09-18.
  8. Wikipedia contributors. Wideband delphi. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Wideband_delphi Accessed 2026-09-18.
  9. Wikipedia contributors. SEER-SEM. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/SEER-SEM Accessed 2026-09-18.
  10. Wikipedia contributors. Program evaluation and review technique. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique Accessed 2026-09-18.
  11. Wikipedia contributors. Three-point estimation. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Three-point_estimation Accessed 2026-09-18.
  12. Wikipedia contributors. Planning poker. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Planning_poker Accessed 2026-09-18.
  13. Wikipedia contributors. Story point. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Story_point Accessed 2026-09-18.
  14. Wikipedia contributors. Source lines of code. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Source_lines_of_code Accessed 2026-09-18.
  15. Wikipedia contributors. Software metric. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Software_metric Accessed 2026-09-18.
  16. Wikipedia contributors. Software sizing. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Software_sizing Accessed 2026-09-18.
  17. Wikipedia contributors. Software development effort estimation. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Software_development_effort_estimation Accessed 2026-09-18.
  18. Wikipedia contributors. Software cost estimation. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Software_cost_estimation Accessed 2026-09-18.
  19. Wikipedia contributors. Cost estimation. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Cost_estimation Accessed 2026-09-18.
  20. Wikipedia contributors. Software project management. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Software_project_management Accessed 2026-09-18.
  21. Wikipedia contributors. Person-month. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Person-month Accessed 2026-09-18.
  22. Wikipedia contributors. Brooks's law. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Brooks%27s_law Accessed 2026-09-18.
  23. Wikipedia contributors. The Mythical Man-Month. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/The_Mythical_Man-Month Accessed 2026-09-18.
  24. Wikipedia contributors. No Silver Bullet. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/No_Silver_Bullet Accessed 2026-09-18.
  25. Wikipedia contributors. Technical debt. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Technical_debt Accessed 2026-09-18.
  26. Wikipedia contributors. Code reuse. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Code_reuse Accessed 2026-09-18.
  27. Wikipedia contributors. Software maintenance. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Software_maintenance Accessed 2026-09-18.
  28. Wikipedia contributors. Legacy system. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Legacy_system Accessed 2026-09-18.
  29. Wikipedia contributors. Lehman's laws of software evolution. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution Accessed 2026-09-18.
  30. Wikipedia contributors. Software quality assurance. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Software_quality_assurance Accessed 2026-09-18.
  31. Wikipedia contributors. Programming productivity. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Programming_productivity Accessed 2026-09-18.
  32. Wikipedia contributors. Software engineering. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Software_engineering Accessed 2026-09-18.
  33. Wikipedia contributors. Fred Brooks. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Fred_Brooks Accessed 2026-09-18.
  34. Wikipedia contributors. Barry Boehm. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Barry_Boehm Accessed 2026-09-18.
  35. Wikipedia contributors. Olaf Helmer. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Olaf_Helmer Accessed 2026-09-18.
  36. Wikipedia contributors. Mike Cohn. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Mike_Cohn Accessed 2026-09-18.
  37. Wikipedia contributors. The Cathedral and the Bazaar. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar Accessed 2026-09-18.
  38. Wikipedia contributors. Open-source software. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Open-source_software Accessed 2026-09-18.
  39. Wikipedia contributors. Free and open-source software. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Free_and_open-source_software Accessed 2026-09-18.

Peer-reviewed papers and technical reports (24)

  1. McCabe, T. J. (1976). A complexity measure. IEEE Transactions on Software Engineering, SE-2(4), 308–320. DOI: https://doi.org/10.1109/TSE.1976.233837 Accessed 2026-09-18.
  2. Putnam, L. H. (1978). A general empirical solution to the macro software sizing and estimating problem. IEEE Transactions on Software Engineering, SE-4(4), 345–361. DOI: https://doi.org/10.1109/TSE.1978.231521 Accessed 2026-09-18.
  3. Dalkey, N., & Helmer, O. (1963). An experimental application of the Delphi method to the use of experts. Management Science, 9(3), 458–467. DOI: https://doi.org/10.1287/mnsc.9.3.458 Accessed 2026-09-18.
  4. Boehm, B., & Basili, V. R. (2001). Software defect reduction top 10 list. Computer (IEEE), 34(1), 135–137. DOI: https://doi.org/10.1109/2.962984 Accessed 2026-09-18.
  5. Jørgensen, M., & Shepperd, M. (2007). A systematic review of software development cost estimation studies. IEEE Transactions on Software Engineering, 33(1), 33–53. DOI: https://doi.org/10.1109/TSE.2007.256943 Accessed 2026-09-18.
  6. Jørgensen, M. (2004). A review of studies on expert estimation of software development effort. Journal of Systems and Software, 70(1–2), 37–60. DOI: https://doi.org/10.1016/S0164-1212(02)00156-5 Accessed 2026-09-18.
  7. Moløkken, K., & Jørgensen, M. (2003). A review of software surveys on software effort estimation. Proceedings of the 2003 International Symposium on Empirical Software Engineering (ISESE), 223–230. IEEE. DOI: https://doi.org/10.1109/ISESE.2003.1237981 Accessed 2026-09-18.
  8. Brooks, F. P., Jr. (1987). No silver bullet: essence and accidents of software engineering. Computer (IEEE), 20(4), 10–19. DOI: https://doi.org/10.1109/MC.1987.1663532 Accessed 2026-09-18.
  9. Boehm, B. W. (1984). Software engineering economics. IEEE Transactions on Software Engineering, SE-10(1), 4–21. DOI: https://doi.org/10.1109/TSE.1984.5010193 Accessed 2026-09-18.
  10. Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., & Selby, R. (1995). Cost models for future software life cycle processes: COCOMO 2.0. Annals of Software Engineering, 1(1), 57–94. DOI: https://doi.org/10.1007/BF02249046 Accessed 2026-09-18.
  11. Albrecht, A. J., & Gaffney, J. E., Jr. (1983). Software function, source lines of code, and development effort prediction: a software science validation. IEEE Transactions on Software Engineering, SE-9(6), 639–648. DOI: https://doi.org/10.1109/TSE.1983.235271 Accessed 2026-09-18.
  12. Kemerer, C. F. (1987). An empirical validation of software cost estimation models. Communications of the ACM, 30(5), 416–429. DOI: https://doi.org/10.1145/22899.22906 Accessed 2026-09-18.
  13. Munson, J. C., & Elbaum, S. G. (1998). Code churn: a measure for estimating the impact of code change. Proceedings of the International Conference on Software Maintenance (ICSM), 24–31. IEEE. DOI: https://doi.org/10.1109/ICSM.1998.738486 Accessed 2026-09-18.
  14. Nagappan, N., & Ball, T. (2005). Use of relative code churn measures to predict system defect density. Proceedings of the 27th International Conference on Software Engineering (ICSE), 284–292. ACM. DOI: https://doi.org/10.1145/1062455.1062514 Accessed 2026-09-18.
  15. Malcolm, D. G., Roseboom, J. H., Clark, C. E., & Fazar, W. (1959). Application of a technique for research and development program evaluation. Operations Research, 7(5), 646–669. DOI: https://doi.org/10.1287/opre.7.5.646 Accessed 2026-09-18.
  16. Anda, B., Angelvik, E., & Ribu, K. (2002). Improving estimation practices by applying use case models. Product Focused Software Process Improvement (PROFES 2002), Lecture Notes in Computer Science, 383–397. Springer. DOI: https://doi.org/10.1007/3-540-36209-6_32 Accessed 2026-09-18.
  17. Lehman, M. M. (1980). Programs, life cycles, and laws of software evolution. Proceedings of the IEEE, 68(9), 1060–1076. DOI: https://doi.org/10.1109/PROC.1980.11805 Accessed 2026-09-18.
  18. Mockus, A., Fielding, R. T., & Herbsleb, J. D. (2002). Two case studies of open source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology, 11(3), 309–346. DOI: https://doi.org/10.1145/567793.567795 Accessed 2026-09-18.
  19. Cunningham, W. (1992). The WyCash portfolio management system. ACM SIGPLAN OOPS Messenger, 4(2), 29–30. DOI: https://doi.org/10.1145/157710.157715 Accessed 2026-09-18.
  20. Raymond, E. S. (1998). The cathedral and the bazaar. First Monday, 3(3). https://firstmonday.org/ojs/index.php/fm/article/view/578 Accessed 2026-09-18.
  21. Albrecht, A. J. (1979). Measuring application development productivity. Proceedings of the IBM Applications Development Symposium (GUIDE/SHARE). IBM. Original function point paper; no stable public URL.
  22. Karner, G. (1993). Resource estimation for Objectory projects. Objective Systems SF AB. Original use case points report; no stable public URL.
  23. Chulani, S., & Boehm, B. (1999). Modeling software defect introduction and removal: COQUALMO (COnstructive QUALity MOdel). Technical report. USC Center for Software Engineering. No stable public URL located.
  24. Dalkey, N. C. (1969). The Delphi method: an experimental study of group opinion (RM-5888-PR). RAND Corporation research memorandum. RAND Corporation. Companion RAND report to the 1963 Management Science paper.

Books and standards (13)

  1. Boehm, B. W. (1981). Software Engineering Economics. Prentice-Hall. ISBN 0-13-822122-7. https://openlibrary.org/isbn/0138221227 Accessed 2026-09-18.
  2. Boehm, B. W., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., Madachy, R., Reifer, D. J., & Steece, B. (2000). Software Cost Estimation with COCOMO II. Prentice Hall. ISBN 0-13-026692-2. https://openlibrary.org/isbn/0130266922 Accessed 2026-09-18.
  3. Halstead, M. H. (1977). Elements of Software Science. Elsevier North-Holland. ISBN 0-444-00205-7.
  4. Brooks, F. P., Jr. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. ISBN 0-201-00650-2. https://openlibrary.org/isbn/0201006502 Accessed 2026-09-18.
  5. Putnam, L. H., & Myers, W. (1992). Measures for Excellence: Reliable Software on Time, Within Budget. Yourdon Press / Prentice Hall. ISBN 0-13-567694-0. https://openlibrary.org/isbn/0135676940 Accessed 2026-09-18.
  6. Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall. ISBN 0-13-147941-5.
  7. McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press. ISBN 0-7356-0535-1. https://openlibrary.org/isbn/0735605351 Accessed 2026-09-18.
  8. Sommerville, I. (2015). Software Engineering. 10th ed.. Pearson. ISBN 978-0-13-394303-0. https://openlibrary.org/isbn/9780133943030 Accessed 2026-09-18.
  9. Gregory, J. (2019). Game Engine Architecture. 3rd ed.. CRC Press. ISBN 978-1-138-03545-4.
  10. Galorath, D. D., & Evans, M. W. (2006). Software Sizing, Estimation, and Risk Management. Auerbach Publications. ISBN 0-8493-3593-0. https://openlibrary.org/isbn/0849335930 Accessed 2026-09-18.
  11. Kroll, P., & Kruchten, P. (2003). The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP. Addison-Wesley. ISBN 0-321-16609-4. https://openlibrary.org/isbn/0321166094 Accessed 2026-09-18.
  12. Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison-Wesley. ISBN 0-201-57168-4. https://openlibrary.org/isbn/0201571684 Accessed 2026-09-18.
  13. International Function Point Users Group (IFPUG) (2010). Function Point Counting Practices Manual, Release 4.3.1. IFPUG. https://www.ifpug.org/ Accessed 2026-09-18.

Measurement tools, datasets and related open-source research (5)

  1. Wheeler, D. A.. SLOCCount: count source lines of code and estimate development effort. dwheeler.com. https://dwheeler.com/sloccount/ Accessed 2026-09-18.
  2. Wheeler, D. A.. SLOCCount user guide. dwheeler.com. https://dwheeler.com/sloccount/sloccount.html Accessed 2026-09-18.
  3. Wheeler, D. A. (2001). More than a gigabuck: estimating GNU/Linux’s size (Red Hat Linux 7.1). dwheeler.com. https://dwheeler.com/sloc/redhat71-v1/redhat71sloc.html Accessed 2026-09-18.
  4. . Halstead metrics documentation. Verifysoft Technology GmbH. Verifysoft Technology GmbH. https://www.verifysoft.com/en_halstead_metrics.html Accessed 2026-09-18.
  5. Wikipedia contributors. Open Hub (formerly Ohloh): overview. Wikipedia, The Free Encyclopedia. Wikimedia Foundation. https://en.wikipedia.org/wiki/Black_Duck_Open_Hub Accessed 2026-09-18.

Machine-readable copy: /history/sources.json. Sources whose hosts block automated clients (Fandom wikis, Open Hub, Slashdot, SourceForge, Giant Bomb, ResetEra) were located through search but could not be fetched directly during the audit.

This analysis is offered as a good-faith, source-linked attempt to quantify something normally left to vibes. Every model has stated assumptions and limitations inline; where a number could not be verified against a primary source, that is disclosed rather than smoothed over. Corrections and better sources are welcome via the community channels.