Your Code Works. That’s the Problem.
When “Working Code” Becomes the Real Problem
Your code passed all tests.
It went to production.
It scaled.
And then it quietly started wasting resources, every second, every day.
Nothing was broken.
And that’s exactly why no one noticed.
If you are a senior developer/architect, you’ve likely encountered these problems multiple times in your career.
Hold those examples in your mind. You’ll likely recognize them by the end.
Welcome to “Beyond the Stack now.” This marks the start of April’s theme: Sustainability.
April is often called a “fool’s month.” And Sustainability has a similar problem.
The real issue is not that problems exist.
It’s that they are not recognized as problems at all.
Over the last two months, we explored how systems are built, through Reliability and Operational Excellence, across coding, AI, and system design.
This week, we look at something more uncomfortable and challenging:
How many serious issues have you seen in code that was running perfectly fine for years?
If you’re building or operating production systems, consider subscribing.
I write about how real systems behave—not just how they’re designed.
When “Correct” Code Fails in Production
A few months ago, we faced a delay in a critical processing flow.
The system didn’t crash.
There were no alerts.
No exceptions.
But the process took nearly 6 hours longer than expected.
The root cause was:
Not infrastructure.
Not scale.
Not dependencies.
It was a single logic statement inside a loop.
A condition that looked harmless:
Executed millions of times
Triggered unnecessary computation
Added latency in every iteration
Individually insignificant.
At scale, catastrophically expensive.
The code was correct.
It did exactly what it was supposed to do.
And that was the problem.
The Illusion of “Working Software”
Most teams optimize for:
Passing tests
Shipping features
Meeting deadlines
Very few optimize for:
How much CPU does this code consume?
How often does this logic run in production?
What does this cost over weeks, months, years?
This creates a blind spot.
Code that works is considered done.
Efficient code? Rarely scrutinized.
Take Twitter's early days (now X): A global counter updated on every view request recomputed the count inefficiently for millions of users, spiking CPU until refactored to cache increments. It worked fine at a small scale, but silently drained resources as it grew.
A Small Experiment: Measuring “Green” Code
During a recent stretch assignment, we explored a different question:
Can we detect inefficient code before it becomes a problem?
We built a small proof of concept using the Creedengo library, an open-source tool focused on identifying energy-inefficient patterns in code.
The goal wasn’t to enforce rules.
It was to create visibility.
The scan surfaced patterns we usually ignore:
Loops that are doing more work than necessary
Redundant API calls
Inefficient data handling
Polling where events would suffice
None of these would fail a test case.
All of them would quietly consume resources.
Where Systems Waste Without Breaking
From both experience and the PoC, a few patterns consistently showed up:
1. Work Done Too Often
Logic placed inside loops that could be moved outside.
2. Data Over-fetching
Pulling entire datasets when only a subset is needed.
3. Chatty Services
Multiple small calls instead of fewer meaningful ones.
4. Polling Instead of Events
Systems ask repeatedly instead of reacting once.
5. Ignored Complexity
An inefficient algorithm that “works” but doesn’t scale.
None of these is a visible failure; they’re perpetual leaks
Creedengo’s ruleset now covers over 500 such patterns across languages, including SQL inefficiencies added in 2025
Programming Languages Don’t Save You
Different languages shift the trade-offs:
Some make it easy to write code quickly.
Some give better control over performance.
Some hide complexity behind abstractions.
For instance, Java’s GC hides leaks but doesn’t prevent them; Rust’s ownership aids efficiency but ignores loop waste
But no language prevents inefficiency.
A poorly placed loop is expensive in any language.
An unnecessary call is wasteful in every stack.
The problem is rarely the language.
It’s what we choose to ignore.
Sustainable Code Is a Different Mindset
Sustainable code is not about perfection.
It’s about awareness.
A few practical shifts:
Write code that does less work, not just faster work
Question logic inside frequently executed paths.
Prefer event-driven flows over constant checking.
Avoid unnecessary abstraction layers.
Fix obvious inefficiencies before measuring everything.
This is not premature optimization.
This is avoiding predictable waste.
Operational Excellence Meets Sustainable Engineering
Operational excellence reacts to problems:
Incidents
Failures
Performance degradation
Sustainable engineering prevents them:
By reducing unnecessary work
By eliminating inefficiency early
By designing for long-term cost, not just short-term success
Operational excellence fixes what breaks.
Sustainable code questions what never breaks—but keeps wasting.
Related Read
Series Note
examining how systems degrade in production due to inefficient resource usage, even when all tests pass.
It also sits at the intersection of two ongoing tracks on Beyond the Stack now:
Programming & Code-Level Decisions
How small, local choices—loops, logging, memory usage, control flow—shape system behavior in production.Sustainability
How efficiency, cost, and predictability are designed (or ignored) long before dashboards reveal issues.
Explore the full Programming & Code-Level Decisions Series
https://beyondthestacknow.substack.com/t/programming-languages
Explore the full Sustainability Engineering Series
https://beyondthestacknow.substack.com/t/sustainability
Closing Thought
That one line of code delayed a system by 6 hours.
But the more important question is:
How many such lines are running right now…
quietly consuming resources,
And no one is noticing?
Your code works.
And that might be the problem.