The romantic image of software engineering is building something new from a blank page. The reality is mostly the opposite: understanding, changing, and fixing code that already exists, usually written by someone who has long since left. Maintenance dominates the lifetime cost of software, and reading old code is what engineers spend most of their day doing. Hiring and process that ignore this optimize for the rare case.
Key Takeaways
- Maintenance consumes 60 to 80% of a software system's total lifetime cost (software maintenance cost data).
- Organizations spend 55 to 80% of IT budgets maintaining existing systems (industry data).
- Developers spend the majority of their time understanding existing code, not writing new code (program comprehension research).
- Optimize your team and hiring for working in existing systems, because that's the actual job.
The Numbers
The data on where software effort actually goes is lopsided and consistent. The IEEE and multiple industry sources put maintenance at 60 to 80% of a system's total lifecycle cost, and organizations spend well over half their IT budgets, by some estimates 55 to 80%, just keeping existing systems running (software maintenance cost data). Even the "building" part is mostly reading: research finds developers spend the majority of their time, on the order of 60%, understanding existing code rather than writing new lines (program comprehension research). Writing brand-new code on a clean slate is the small slice; maintenance is the main event.
Why This Matters for How You Hire
Most technical interviews test the rare thing. A candidate solves a clean, isolated algorithm puzzle from scratch, when the actual job is landing safely in a large, messy, unfamiliar codebase and changing it without breaking things. Those are different skills. The engineer who can quickly understand a gnarly existing system, form a mental model of code they didn't write, and make a careful change is worth far more day-to-day than the one who's only fast on a blank page, precisely because the blank page is rare. This is why we test for working in realistic, existing code rather than whiteboard puzzles, part of the take-home vs live coding and structured interview thinking.
| The interview tests | The job requires |
|---|---|
| Greenfield puzzle from scratch | Changing a large existing system |
| Clean isolated problem | Messy, coupled, real code |
| Writing new code fast | Understanding old code safely |
A Concrete Version
A team hires an engineer who aced the from-scratch coding rounds. On day one they meet the reality: a six-year-old codebase, sparse docs, original authors gone, and a bug buried in code nobody fully understands. The skill that got them hired, writing clean new code fast, barely applies. What matters now is reading carefully, forming a model of the existing system, and changing it without triggering the hidden side effects. The engineers who thrive are good at exactly the thing the interview didn't test.
Working Well With Legacy Code
Because legacy work is the main event, treat it as a first-class skill. Michael Feathers' book Working Effectively with Legacy Code made the canonical case: the safe way to change old code is to get it under test first, then change it in small, verified steps, rather than heroically rewriting it, which usually fails. Good documentation and a healthy bus factor make legacy code far less scary, because the knowledge to change it safely lives somewhere other than one person's memory.
What This Means for Teams
The dominance of maintenance changes what "a strong engineer" means. The most valuable engineers are the ones who can walk into an unfamiliar, imperfect system and become productive in it quickly and safely, which is exactly the capability our vetting is designed to surface, and a core reason placed engineers who ramp fast pay off. Hire for the real job, working in code that already exists, and you hire for reality. See available engineers.
Frequently Asked Questions
How much of software cost is maintenance?
Industry and IEEE sources put maintenance at 60 to 80% of a system's total lifetime cost, and organizations spend 55 to 80% of IT budgets maintaining existing systems. New development is the minority.
What do developers actually spend their time on?
Mostly understanding existing code. Research finds program comprehension, on the order of 60% of the time, is the dominant activity, ahead of writing new code.
Why does this matter for hiring?
Because most interviews test greenfield, from-scratch coding, while the real job is changing large existing systems safely. Those are different skills, and the second one matters far more day-to-day.
How do you work safely in legacy code?
Get the code under test before changing it, then make small, verified changes, the approach from Feathers' Working Effectively with Legacy Code. Good docs and a healthy bus factor help a lot.
The Bottom Line
Software engineering is mostly maintenance rather than greenfield: maintenance is 60 to 80% of a system's lifetime cost, and reading existing code is what engineers do most. Hire and build process for the real job, understanding and safely changing code that already exists, and stop optimizing for the blank page that rarely appears.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
