Rails applications from 2010 still running in production unchanged. Angular 1.x applications forced into complete rewrites after 18 months. Both decisions made in similar timeframes. Radically different longevity outcomes.
This guide is part of our comprehensive decision longevity framework, where we explore how understanding time horizons transforms your approach to technical leadership.
Here’s the thing – you’re probably spending equal time debating decisions that have a 10x difference in lifespan. Hours arguing over which frontend framework to use (18-month typical lifespan) and hours debating database choices (7-10 year commitment). This misalignment creates waste.
Code half-life gives you a quantitative metric for when 50% of your code will need replacement. Erik Bernhardsson’s research analysed 26+ open-source projects and found a median of 3.33 years, with a range from 0.32 years (Angular) to 6.6 years (Linux kernel). That’s useful data.
Use this framework to match debate investment to expected decision longevity. There’s a hierarchy: Language choices last 10+ years, databases 7-10, hosting providers 3-5, backend frameworks 3-5, libraries 2-3, frontend frameworks 18 months. Match your discussion time to the expected lifespan and you’ll stop wasting time on short-lived decisions.
This gives you quantitative data for defending framework choices to stakeholders, ROI calculations for architectural debates, and tools for tracking when technologies approach obsolescence. Building on the temporal multiplier analysis from our core framework, these quantitative methods enable data-driven prioritisation of technical debates.
What Is Code Half-Life and How Do We Measure It?
Code half-life is the time period after which 50% of your codebase lines will be replaced or modified.
You measure it using Git blame analysis tracking when each code line was last changed. Erik Bernhardsson’s “Git of Theseus” methodology analyses version control history using exponential decay models. He looked at 26+ open-source projects and found a median of 3.33 years. But there’s a range – 0.32 years for Angular at the low end, all the way to 6.6 years for the Linux kernel.
The Git blame analysis method tracks code line modifications over time, calculates survival rates per commit, and fits it all to an exponential decay curve.
The exponential decay model is borrowed from physics and chemistry. Code has a constant risk of being replaced, similar to radioactive decay. All models are wrong, some models are useful – and this one has explanatory power.
You can run Git of Theseus on your own repository, compare against industry benchmarks, and identify which modules are stable and which are churning. The quality indicator works like this: High half-life (5+ years) suggests modular architecture. Low half-life (<1 year) indicates architecture instability or rapid feature churn.
Git itself shows 40% of code still present after 10 years. That’s high stability from a well-architected system.
Why Do Different Frameworks Have Such Different Half-Lives?
Angular: 0.32 years. Breaking changes every version, forced rewrites.
React: 1.66 years. Gradual evolution, deprecation warnings that give you time to adapt.
Rails: 2.43 years. Stable conventions, incremental upgrades.
Django: 3.38 years. Backward compatibility commitment.
Linux kernel: 6.6 years. Modular architecture, linear scalability.
The variance is driven by architecture modularity, breaking change frequency, and ecosystem maturity.
Frontend frameworks churn. Typical lifespan is 18 months to 3 years. Rapid API changes. The way we write code has fundamentally changed in the last 10 years, and the JavaScript ecosystem is volatile.
Backend frameworks are more stable. Typical lifespan is 3-5 years. More mature conventions. Enterprise adoption requires stability, so frameworks that want enterprise customers build for it.
Modular architecture has real impact. The Linux kernel’s drivers directory contains 22,091 files with well-defined interfaces enabling independent replacement. That’s why it has a 6.6 year half-life.
Linear scalability extends code longevity. Moment.js has a 4.54 year half-life because so much of the code is locale-specific. New features add code without modifying core, which prevents cascading rewrites.
Breaking change frequency matters. Angular’s versioning strategy forced migrations. React’s deprecation approach extended lifespan by giving developers time to adapt.
Ecosystem maturity shows up in the data. Express.js has a 1.23 year half-life despite being 7 years old, likely from lack of linear scalability and early JavaScript ecosystem immaturity.
How Does Framework Half-Life Compare Across Ecosystems?
JavaScript frontend: Highest churn (Angular 0.32y, React 1.66y).
Python backend: Most stable (Django 3.38y, NumPy 4.15y, SciPy 4.62y).
Ruby backend: Mid-range (Rails 2.43y).
Node.js backend: Variable (Express 1.23y despite maturity).
The pattern is clear: Frontend frameworks 18 months to 3 years, backend frameworks 3-5 years.
Here’s the complete data from Erik Bernhardsson’s research:
Frontend Frameworks:
- Angular: 0.32 years
- React: 1.66 years
- Backbone: 1.48 years
Backend Frameworks:
Infrastructure:
Libraries:
- Underscore: 1.97 years
- Requests: 2.10 years
- NumPy: 4.15 years
- SciPy: 4.62 years
- Moment: 4.54 years
Newer Tech:
- Kubernetes: 0.59 years
- TensorFlow: 1.08 years
- Keras: 0.69 years
Infrastructure projects show the longest half-lives. Language and database decisions justify thorough architectural review (5-10+ years). Backend framework selection merits careful evaluation given 3-5 year expected relevance.
This pattern suggests allocating minimal debate time to frontend framework choices. You’re going to replace it anyway.
What Is the Decision Decay Hierarchy and How Do I Use It?
Programming language choice: 10+ years typical longevity.
Database selection: 7-10 years (migration is costly).
Hosting provider: 3-5 years (vendor lock-in concerns).
Backend framework: 3-5 years (ecosystem stability).
Library choices: 2-3 years (easier to replace).
Frontend framework: 18 months (plan for replacement from day one).
Authentication patterns: 5+ years (security requirements stay stable).
Use the hierarchy to allocate debate time proportionally to expected decision lifespan. This framework selection by timeline approach ensures your half-life data directly informs technology choices across different project horizons.
Language decisions deserve days of debate. Python, Java, JavaScript longevity affects your entire ecosystem. Hiring pool persistence matters. The ripple effects last a decade.
Database decisions deserve thorough architectural review. PostgreSQL and MySQL have long-standing stability. But migration complexity and cost is high. Your data model creates lock-in. A bad database choice haunts you for 7-10 years.
Hosting provider decisions deserve hours of comparison. AWS, Azure, GCP commitment periods matter. Vendor lock-in mitigation strategies need thought. But you can migrate if you have to.
Framework decisions split. Backend framework selection merits careful evaluation – you’re living with it for 3-5 years. Frontend framework selection deserves minimal debate because you’ll replace it relatively soon.
Library choices are relatively easy to swap. Date handling, HTTP clients, logging libraries – these deserve minutes of discussion, not hours. Don’t over-invest here.
Authentication patterns deserve substantial debate. JWT, OAuth, session-based approaches – security requirements change slowly. A good authentication architecture lasts 5+ years.
The practical application is simple. Match debate hours to expected years of relevance. Avoid over-investing in short-lived decisions. Focus deep analysis on long-term commitments.
How Do I Calculate the ROI of Architectural Debates?
The Decision Investment Formula balances decision longevity, switching cost, and team size to determine appropriate debate duration.
Language and database decisions: Days of debate justified (10-year lifespan).
Backend framework: Hours of debate appropriate (3-5 year lifespan).
Frontend framework: Minutes to one hour maximum (18-month lifespan).
Library selection: Minutes only (2-3 year lifespan, low switching cost).
The calculation: If a decision affects 10 developers for 5 years (50 person-years), you can justify 2-3 days of collective debate.
The formula has four components. Decision longevity (expected years). Switching cost (person-months to migrate). Team size (developers affected). Reversibility (can the decision be undone incrementally).
Worked example – Language choice: A language choice affecting 20 developers for 10 years with high switching costs justifies 3-5 days of research and debate. You’re making a decade-long commitment. Think it through.
Worked example – Frontend framework: A frontend framework affecting 5 developers for 18 months with moderate switching costs justifies 2-4 hours of comparison maximum. You’re replacing it soon anyway. Pick something reasonable and move on.
Worked example – Library choice: A library choice affecting 3 developers for 2 years with low switching costs requires 30 minutes discussion sufficient. Libraries are easy to swap. Don’t overthink it.
Initial research has high value. Extended debate rarely changes decision quality beyond a certain point.
Document your decision rationale regardless of debate duration. Architecture Decision Records should capture longevity assumptions. When those assumptions change (framework announces early deprecation), you have context for re-evaluation.
The 80/20 Rule applies here too. Focus on the high-impact 20% of decisions that create 80% of long-term consequences. That’s your language, database, and core architecture choices. Everything else is replaceable.
What Tools Help Track When Technologies Are Approaching Obsolescence?
endoflife.date: Technology End-of-Life dates and support timelines for 400+ products.
Stack Overflow Developer Survey: Annual trends for 314 technologies across 49,000+ developers.
ThoughtWorks Technology Radar: Twice-yearly framework adoption lifecycle assessments.
FOSSA: Software composition analysis tracking dependency age and vulnerabilities.
GitHub activity metrics: Commit frequency, contributor counts, issue response times.
Vendor support roadmaps: Oracle Java SE, Microsoft .NET official timelines.
endoflife.date gives you a comprehensive EOL database with an API. Covers languages, frameworks, databases, operating systems. Provides security update timelines so you know when you’re running unsupported software.
The Stack Overflow Developer Survey shows “most loved/dreaded” technology rankings. Year-over-year adoption trends. Technology usage percentages. You can identify declining momentum before it becomes obvious.
ThoughtWorks Technology Radar uses Adopt/Trial/Assess/Hold classifications for technology maturity. Twice-yearly updates keep you current.
FOSSA provides automated dependency scanning, obsolescence alerts, security vulnerability tracking, and licence compliance monitoring. Useful for tracking the age of your dependencies.
GitHub activity metrics work as a popularity proxy. Stars and forks indicate interest. Commit frequency shows active maintenance. Contributor count reveals community health. Issue closure rate demonstrates responsiveness. When these metrics decline, your technology is approaching obsolescence.
npm and PyPI download trends show package growth or decline. Watch for alternative packages emerging. Those are ecosystem shift indicators.
Vendor roadmaps provide fixed deadlines. Oracle Java SE support until 2030+. Microsoft .NET LTS timelines. Database vendor commitments. When you have vendor dates, you can plan migrations with certainty.
Community monitoring matters too. Stack Overflow question volume declining. Reddit and Hacker News sentiment shifts. Conference and meetup activity reduction. These are leading indicators.
Track technology velocity quarterly. Assign a rating from -5 to +5 for each technology. Negative scores indicate depreciation. Positive scores indicate appreciation. Do this every quarter and you’ll spot trends before they become problems.
How Do I Measure the Half-Life of My Own Codebase?
Use Git blame analysis to track when each code line was last modified. Run Erik Bernhardsson’s “Git of Theseus” tool on your repository. Calculate replacement rate: percentage of code surviving from each historical commit. Fit data to exponential decay curve to determine half-life. Compare against the 3.33 year industry median.
Half-life <1 year suggests architecture instability. Half-life >5 years indicates strong modularity. But context matters.
Git of Theseus analyses your repository to generate survival curve graphs showing code replacement patterns over time. The analysis process aligns commits at x=0, calculates aggregate decay, and fits an exponential model.
Interpretation is contextual. Above median (>3.33 years) suggests stable architecture or mature product. Below median (<3.33 years) indicates rapid evolution or poor modularity. Neither is automatically good or bad.
Module-level analysis gives you architectural insights. Measure half-life per directory or module. Identify stable core vs churning periphery. This reveals architectural quality in ways aggregate metrics can’t.
Re-run quarterly for trend analysis. Improving half-life (longer survival) suggests architecture stabilising. Declining half-life (shorter survival) indicates increasing churn or instability. One-time measurement is a data point. Trend over time is an architectural health indicator.
Compare against similar projects in your ecosystem. Frontend applications expect lower half-life. Backend services expect higher. Don’t compare your React app to the Linux kernel.
Action items are straightforward. Low half-life (<1 year) → investigate architecture issues. Something is causing excessive churn. High half-life (>5 years) in an actively-developed product may indicate insufficient innovation or technical debt accumulation. You might be avoiding changes because the system is brittle.
When Should I Start Planning to Replace My Technology Choices?
At half-life point (50% replacement probability): Begin migration planning.
At 75% of expected lifespan: Active migration preparation required.
Monitor continuously using endoflife.date, ThoughtWorks Radar, community metrics.
Obsolescence warning signs are clear. Declining GitHub activity. Security patches slowing. Hiring difficulty. Stack Overflow question volume dropping. When you see these, start planning. Understanding framework obsolescence as a rewrite trigger helps you distinguish between natural replacement cycles and signals requiring immediate action.
Vendor support ending is a fixed deadline. No flexibility there. You have to migrate.
Use the Strangler Fig pattern for incremental replacement. The pattern enables gradual replacement strategy ensuring business continuity. You incrementally replace legacy functionalities with new applications. A routing layer manages requests between legacy and modern components, minimising disruption.
There are three phases: Transform (identify and create new services), Coexist (keep old system running while new system handles some requests), Eliminate (remove legacy components as new system proves stable).
Budget 12-18 month transitions. Account for training and productivity dip. Migration is never as fast as you think.
When selecting replacement technology, repeat the Decision Longevity Hierarchy analysis. Prioritise stability over novelty for replacements. You’re migrating because the current technology didn’t last. Don’t make the same mistake twice.
Evaluate emerging vs mature alternatives. Emerging technology might be exciting but it lacks the track record. Mature alternatives have known half-lives and demonstrated stability.
FAQ Section
How is code half-life different from technical debt?
Code half-life measures natural replacement rate – how quickly code changes for any reason. Technical debt measures quality gap requiring remediation. They’re different metrics.
High technical debt can reduce half-life by forcing rewrites. But stable architectures with low debt can still have short half-lives due to rapid feature evolution. Half-life is descriptive. Technical debt is prescriptive.
Does longer code half-life always mean better architecture?
Not necessarily. Extremely long half-life (>7 years) in actively-developed products may indicate insufficient innovation, accumulated technical debt, or fear of changing brittle systems.
Context matters. The Linux kernel’s long half-life reflects healthy modularity. A startup with similar longevity might signal stagnation. Optimal range: 3-5 years for most business applications.
Should I avoid frameworks with short half-lives?
Short framework half-life doesn’t make it the wrong choice—it makes it a predictable replacement that you should plan for from the start.
The mistake is debating Angular vs React for days when both have short half-lives and the decision longevity doesn’t justify the investment. Choose quickly, plan for replacement, focus debate time on database and language choices.
How does skill half-life relate to code half-life?
Framework-specific expertise decays at approximately the same rate as framework code. 18-24 months for frontend frameworks.
Professional skill half-life has plummeted from 30 years to approximately 5 years according to Deloitte research. Technical skills depreciate 2-5x faster than human skills.
Implication: Invest learning time in long-lived fundamentals (algorithms, architecture patterns, language mastery) over short-lived framework APIs. Framework skills are disposable. Foundational skills compound. Understanding these skill decay considerations becomes crucial for knowledge transfer timing as your team grows.
Can I improve my codebase’s half-life through refactoring?
Yes. Modular architecture with stable interfaces extends half-life significantly. Linux kernel’s 6.6 years vs Angular’s 0.32 years demonstrates the difference.
Refactor toward: Independent, replaceable components. Stable public APIs. Linear scalability (new features add code, don’t modify existing). Plugin architectures enabling peripheral churn without core changes.
Measure before and after refactoring to quantify improvement.
What if my half-life analysis shows 6-month code survival?
Six-month half-life indicates significant instability. Possible causes: Thrashing on architecture decisions. Excessive refactoring without stability goals. Framework choice with extreme breaking change frequency. Team lacking shared architectural vision.
Actions: Freeze architecture for one quarter. Implement stable interface boundaries. Measure again to verify improvement. Consider if the problem is appropriate rapid experimentation (early startup) vs harmful instability (scaling company).
Should I document decision longevity assumptions in Architecture Decision Records?
Yes. ADRs should include expected decision lifespan (2 years? 10 years?), assumptions about technology stability, switching cost estimates, and triggers for revisiting the decision.
When assumptions invalidate (framework announces deprecation earlier than expected), the ADR provides context for re-evaluation. ADRs serve as a communication tool enabling teams to grasp reasoning behind decisions.
Longevity assumptions are as important as technical rationale.
How do I convince stakeholders to migrate before obvious crisis?
Use half-life data as an objective metric. “We’re at the 75% point of this framework’s expected lifespan. Data shows 80% probability of forced migration within 18 months. Proactive migration costs 6 person-months now. Reactive crisis migration costs 18+ person-months under time pressure.”
Quantitative framing converts subjective “feeling old” to objective risk management. Reference vendor EOL dates as fixed deadlines.
What’s the difference between half-life and End-of-Life date?
Half-life is natural replacement rate (when 50% of code statistically gets rewritten). EOL is vendor-declared support termination (fixed deadline).
Example: Java 8 had a ~4-year half-life in many codebases, but Oracle’s 2030 EOL date is a fixed migration deadline. Half-life guides planning. EOL dictates deadlines.
Monitor both. Half-life for natural evolution. EOL for forced upgrades.
How often should I re-measure my codebase half-life?
Quarterly measurement for actively-developed projects. Track trends.
Improving half-life (longer survival) suggests architecture stabilising. Declining half-life (shorter survival) indicates increasing churn or instability.
Use as a quality metric in engineering reviews. One-time measurement is a data point. Trend over time is an architectural health indicator. You can automate this with Git of Theseus in your CI/CD pipeline.
Are there industries or domains where half-life patterns differ?
Yes. Financial services: Longer half-lives (regulatory stability, risk aversion), typical 5-7 years. Consumer web and mobile: Shorter half-lives (rapid feature iteration), typical 2-3 years. Enterprise SaaS: Mid-range (balance between stability and innovation), typical 3-5 years. Embedded systems: Longest half-lives (hardware constraints), typical 7-10+ years.
Adjust Decision Longevity Hierarchy expectations accordingly.
Can I apply half-life analysis to infrastructure-as-code or DevOps configurations?
Absolutely. Terraform configurations, Kubernetes manifests, CI/CD pipelines all have measurable half-lives. Typically shorter than application code (1-2 years).
The reasons: Infrastructure provider API changes. Security requirement evolution. Tooling ecosystem rapid advancement.
Measure using the same Git blame methodology. Implication: Modularise infrastructure code, expect frequent rewrites, invest less debate time than application architecture decisions.
