Why Developers Never Get Credit for Problems That Never Happened

A 25-year-old MIT Sloan Management Review paper hit the front page of Hacker News this week with 668 upvotes and 219 comments, proving that some engineering problems are truly timeless. "Nobody Ever Gets Credit for Fixing Problems that Never Happened" by Nelson Repenning and John Sterman remains painfully relevant in 2026—perhaps even more so as technical debt compounds across the industry.

The paper's core thesis is deceptively simple: organizations systematically undervalue proactive work because prevented problems are invisible. A security vulnerability patched before exploitation, a performance bottleneck resolved before it causes downtime, a refactoring that prevents six months of maintenance pain—none of these generate the visceral urgency of a production fire.

For developers, this dynamic explains why firefighting always wins priority over fire prevention.

The Capability Trap in Modern Development

Repenning and Sterman describe what they call the "capability trap": teams get stuck in reactive mode because solving visible crises delivers immediate, measurable value. Management sees the problem resolved. Stakeholders see the hero who stayed up all night. The engineer who spent three weeks hardening infrastructure to prevent that exact scenario? They were "just doing maintenance."

This trap has only intensified in the era of rapid deployment and microservices. When teams ship multiple times per day, the pressure to deliver visible features compounds. The pull request that adds a new API endpoint gets celebrated. The PR that refactors error handling across 47 services gets delayed until "after the sprint."

The Hacker News comment thread is filled with war stories: the engineer who automated deployments and eliminated 90% of outages ("nice, but what features did you ship?"), the security team that prevented breaches for five years straight (budget cut in year six), the SRE who made systems so reliable that management questioned whether the role was still needed.

One commenter put it bluntly: "The reward for good ops work is that people forget ops exists."

The Metrics Problem

The paper identifies a measurement challenge that modern engineering teams still haven't solved: how do you quantify a problem that didn't happen?

Incident count went down? Could be luck. Page volume decreased? Maybe traffic dropped. Deploy frequency increased without outages? Hard to tie directly to that specific refactoring from Q2.

Meanwhile, reactive work generates obvious metrics: mean time to recovery, incident severity, customer impact, revenue saved. These numbers are concrete, immediate, and easy to present in status updates.

This measurement asymmetry creates perverse incentives. Engineers learn that preventing problems is invisible, while fixing them is highly visible. The optimal career strategy becomes: let minor issues slide until they become visible crises, then heroically resolve them.

Some teams try to fix this with "blameless postmortems" that celebrate prevention, but the paper's research suggests this isn't enough. Without fundamental changes to how organizations allocate recognition and resources, teams drift back toward reactive mode.

What Actually Works

The Hacker News discussion surfaced several strategies that experienced engineers use to make proactive work visible:

Quantify the counterfactual. One commenter described running "chaos engineering" exercises to demonstrate what would happen without their reliability improvements. By intentionally degrading systems in controlled environments, they made the prevented problems tangible.

Track leading indicators. Monitor metrics that predict future problems: test coverage trends, dependency freshness, security scan findings, performance regression rates. When these improve, you have concrete evidence of proactive work.

Document the near-misses. Every time monitoring catches an issue before it impacts users, write it up. Every time a code review prevents a bug from merging, log it. These create a paper trail of prevented problems.

Make technical debt visible. Tools like CodeScene, SonarQube, or even internal dashboards that surface refactoring needs help translate "maintenance" into concrete work items that stakeholders can understand.

Change the incentive structure. Some organizations explicitly allocate 20-30% of engineering time to proactive work, treating it as non-negotiable infrastructure investment rather than discretionary maintenance.

The 2026 Context

This paper resonates particularly strongly right now because we're seeing the consequences of deferred proactive work at scale:

  • AI-generated code security issues: As Debuggix's recent analysis shows, tools like Cursor and Bolt ship code with systematic security patterns—hardcoded credentials, missing validation, wildcard CORS. The engineers who could have prevented these patterns were probably pressured to ship faster instead.

  • Supply chain vulnerabilities: The ongoing stream of npm, PyPI, and container registry compromises often succeeds because dependency hygiene is invisible work that gets deprioritized.

  • Infrastructure scaling crises: Multiple high-profile outages in 2026 have been traced back to architectural decisions made years ago under pressure to deliver features rather than invest in scalability.

The paper's authors note that escaping the capability trap requires leadership courage: explicitly valuing invisible work, protecting time for proactive improvements, and recognizing that "nothing bad happened" is often the best possible outcome.

The Takeaway

Twenty-five years after publication, Repenning and Sterman's paper remains the definitive explanation for why engineering excellence is so hard to sustain. The dynamics they described—reactive work crowding out proactive work, heroes overshadowing prevention, visible crises dominating invisible improvements—are structural problems that require structural solutions.

For individual developers, the lesson is to make your proactive work visible through documentation, metrics, and storytelling. For engineering leaders, it's to explicitly allocate time and recognition for the problems that never happen.

Because in the long run, the teams that invest in prevention are the ones that ship faster, sleep better, and avoid the burnout spiral of perpetual firefighting.

The fact that this paper is trending again in 2026 suggests we still haven't figured it out—but at least we're still talking about it.

The full paper is available at MIT's website. The Hacker News discussion with 200+ comments is here.