There's an uncomfortable truth in our industry that most people don't want to talk about: the software you're building today has an effective shelf life of about five years. After that, it becomes a liability rather than an asset.
The Five Year Cliff
It's not that software stops working after five years. The code itself is perfectly fine. What changes is everything around it — the ecosystem, the dependencies, the team's understanding of it, and the business requirements it was designed to meet.
Think about what was state-of-the-art five years ago. The frameworks were different. The deployment patterns were different. The security landscape was different. The people who wrote the original code have likely moved on.
Why This Happens
Dependencies rot. Every library you depend on is evolving. After five years, you're typically two or three major versions behind on critical dependencies. Upgrading becomes a project in itself.
Knowledge leaves. The engineers who understood the system's quirks and undocumented behaviors have moved to other roles or companies. New team members inherit a system they can modify but don't truly understand.
Requirements drift. The business has evolved. Features that were critical are now unused. New requirements are shoehorned into an architecture that wasn't designed for them.
Security standards change. What was considered secure five years ago may have known vulnerabilities today. Authentication patterns, encryption standards, and compliance requirements all evolve.
What This Means for How We Build
Accepting the five-year shelf life doesn't mean we should write throwaway code. It means we should build with replaceability in mind.
Keep boundaries clean. Well-defined service boundaries make it possible to replace components independently rather than rewriting everything at once.
Document the why, not just the what. Five years from now, someone needs to understand the business context behind architectural decisions, not just the code itself.
Minimize coupling. Every dependency is a commitment. Be intentional about what you take on.
Plan for migration. The best time to plan how you'll move off a system is when you're building it. Data formats, API contracts, and integration points should all be designed with portability in mind.
The Pragmatic Approach
The most successful engineering organizations I've worked with treat software like infrastructure with a planned lifecycle. They budget for modernization. They schedule rewrites before systems become critical liabilities. They treat technical debt as a financial concept with real carrying costs.
The five-year shelf life isn't a failure of engineering — it's the natural consequence of building in a rapidly evolving landscape. The failure is pretending it doesn't exist.