Frameworks
Frameworks give you a head start. They handle routing, data access, and rendering so your team can focus on what matters. But that head start comes with a long tail. The framework you pick today will shape your hiring, your upgrades, and your maintenance burden for years to come.
Key Statistics
- • 92% of commercial codebases depend on open source frameworks and libraries, making framework maintenance a universal concern. / Synopsys OSSRA Report
- • Large-scale technology migration projects routinely take 12-18 months and exceed initial cost estimates by 2-3x. / McKinsey Technology Transformations Survey
- • 60% of developers say framework upgrades are one of their biggest maintenance challenges. / JetBrains Developer Ecosystem Survey
- • Applications using outdated framework versions are 3x more likely to contain known security vulnerabilities. / Snyk State of Open Source Security Report
Why This Matters
Your framework choice is a bet. A good one accelerates hiring, speeds up onboarding, and gives you a decade of community support. A bad one saddles your team with mounting upgrade costs, a shrinking talent pool, and an ecosystem that's moving on without you.
Framework upgrades are the maintenance challenge nobody plans for. A major version bump can touch every file in your codebase. Fall behind by two versions and you're looking at a project, not a task. Fall behind by three and you're looking at a rewrite conversation.
On the Maintainable Software Podcast, framework creators and practitioners share hard-won lessons about building with, upgrading, and sometimes rescuing applications from their framework choices.
Episodes on Frameworks
EP-211 | August 26, 2025
Taylor Otwell: What 14 Years of Laravel Taught Me About Maintainability
EP-108 | October 4, 2021
DHH: Celebrating Legacy Software as a Victory and the Story of How Humans Can't Estimate
EP-006 | May 20, 2019
Eileen M. Uchitelle: Upgrading Ruby on Rails At Github And How To Stay Updated
EP-182 | September 3, 2024
Noel Rappin: Reviving the Pickaxe— A Journey through Ruby's Legacy
EP-180 | August 20, 2024
Obie Fernandez: Pioneering AI in Ruby on Rails Development
EP-173 | June 18, 2024
Robin Heinze - React Native and the Art of Flexibility
EP-078 | December 7, 2020
Mark Erikson: Accidentally Becoming an Open Source Maintainer
EP-195 | January 14, 2025
Joel Hawksley: The Hidden Costs of Frontend Complexity
EP-048 | March 30, 2020
Kelly Sutton: Custodians of the Monolith
EP-159 | February 6, 2024
Jemma Issroff - Running the Parser in the Rain
Frequently Asked Questions
What is a software framework?
A software framework is a reusable foundation for building applications. It handles common functionality like routing, database access, authentication, and rendering. Ruby on Rails, Laravel, React, and Django are well-known examples. Frameworks enforce conventions that shape how teams write and organize code, for better or worse.
How do you decide when to upgrade a framework?
Upgrade when security patches are no longer available for your version, when your version is approaching end-of-life, or when newer versions offer significant performance or developer experience improvements. The longer you wait, the harder upgrades become. Many teams adopt a policy of staying within one major version of the latest release.
What are the risks of framework lock-in?
Lock-in happens when your application is so tightly coupled to a framework that switching or upgrading becomes prohibitively expensive. You end up stuck with outdated technology, struggling to hire, and exposed to security vulnerabilities in unsupported versions. The best defense is keeping business logic separate from framework code so you can change one without rewriting the other.
How do you migrate from one framework to another?
Successful framework migrations use incremental strategies like the Strangler Fig pattern, where new features are built in the target framework while legacy features are gradually migrated. Avoid big-bang rewrites. Establish shared authentication, build an adapter layer, migrate one route or component at a time, and run both systems in parallel during the transition.
When should you use a framework vs. building from scratch?
Use a framework when your application fits the patterns it handles well, when you want to tap into community knowledge for hiring and problem-solving, and when you need to ship quickly. Build from scratch only when requirements truly demand it, like real-time systems with sub-millisecond latency targets or domains where no existing framework fits your architecture. Most of the time, the framework is the right call.