Why maintaining a codebase is so damn hard – with OhMyZSH creator Robby Russell [Podcast #207]

Developers live inside inherited decisions

Most software work involves navigating constraints from predecessor choices, former self decisions, and existing architecture rather than building from scratch.

Greenfield development is statistically rare

Russell estimates developers spend 99% of their time maintaining existing codebases rather than starting new projects, even when building new features.

Maintenance extends beyond bug fixes

Adding features to existing systems constitutes maintenance because it requires working within established technical constraints and legacy architecture.

Organizations accumulate abandoned repositories

Companies often maintain 80+ repositories where the majority are untouched for years, creating confusion about what is deployed, what is safe to archive, and what dependencies remain active.

Forking creates permanent hidden burdens

Teams frequently fork third-party libraries to patch urgent bugs, creating long-term maintenance responsibilities when those forks aren't merged back upstream or properly documented.

Code lacks clear ownership

When developers leave organizations, they often take irreplaceable tacit knowledge with them, leaving behind codebases that require forensic analysis to understand architectural decisions.

Rewrites risk institutional amnesia

Starting fresh underestimates the complexity embedded in production systems and often represents an expensive way to forget lessons learned from years of iteration.

Production complexity is invisible until lost

Teams routinely underestimate the time and energy invested in existing working systems, viewing rewrites as cheaper than refactoring until they rediscover edge cases the hard way.