Most engineering teams believe they have a productivity problem.

They think development is slow because there are too many meetings, not enough developers, or because the tech stack isn’t modern enough. But after spending time inside real software teams, one uncomfortable pattern keeps appearing again and again: developers are not actually spending most of their time building new things. They’re spending a massive amount of time fixing, rewriting, and correcting work that should have been done correctly the first time.

Research published in the Journal of Systems and Software suggests that software projects can spend nearly 40–50% of development effort on avoidable rework. That number sounds extreme until you look closely at how modern teams operate. A feature gets shipped quickly, but the requirements were vague. Backend and frontend interpret the logic differently. Product changes direction halfway through implementation. APIs need redesigning after integration. Suddenly an entire sprint disappears, not because the team failed to work hard, but because the foundation itself was unstable from the beginning.
And the scary part is that most teams don’t even realize how much time is being lost.

The Invisible Work That Nobody Talks About
One of the biggest problems with rework is that it often looks like “progress” on the surface. Developers are active, pull requests are merged, tickets are moving across the board, and deployments are happening constantly. From a management perspective, everything appears productive.
But inside the engineering workflow, a huge amount of energy is quietly consumed by invisible work.
Engineers jump between fixing edge cases, correcting misunderstood business logic, reviewing AI-generated code, patching integrations, rewriting unstable modules, or refactoring rushed implementations from previous sprints. A 2026 engineering report from Harness described this phenomenon as the rise of “invisible work,” where developers spend increasing amounts of time maintaining momentum instead of creating meaningful forward progress.
Many developers know this feeling personally. You finish coding a feature, only to discover later that the requirement was incomplete. Or worse, you realize the system design itself cannot support the new business case. So instead of building the next feature, the team spends days or weeks repairing existing decisions.
This is the part of software engineering that dashboards rarely capture.

The Real Problem Isn’t Coding, It’s Alignment
A lot of teams assume rework happens because developers make mistakes.
In reality, rework often begins long before coding even starts.
The deeper issue is usually weak alignment between business goals, system design, and technical execution. This is where SDD (Software Design & Documentation) becomes incredibly important, even though many companies still treat documentation as optional or “something we’ll clean up later.”
Ironically, skipping proper design discussions in order to “move faster” often creates the exact opposite result.
When requirements are unclear, every developer fills the gaps differently based on their own assumptions. Product managers imagine one workflow, backend engineers design another, and frontend developers build something slightly different again. Nobody is technically wrong, but the system slowly drifts into inconsistency. By the time these misunderstandings are discovered, the cost of fixing them becomes dramatically higher.
This is why experienced engineers care so much about seemingly boring things like API contracts, edge cases, sequence diagrams, or failure scenarios. They understand that a single unclear assumption early in development can later evolve into weeks of refactoring.
And most teams only notice the problem when delivery timelines begin slipping.

AI Is Speeding Up Code, But Not Understanding
AI coding tools have changed software development dramatically over the past few years. Developers can now generate boilerplate code, build components faster, and automate repetitive implementation tasks in ways that were impossible not long ago.
But there’s an important distinction many companies are beginning to learn the hard way:
AI accelerates code generation.
It does not automatically improve system thinking.
A recent report found that 81% of developers now spend more time reviewing code after adopting AI-assisted tools. That insight is incredibly revealing because it highlights a common misconception in modern engineering culture: people assume faster coding automatically means faster development.
But software engineering has never been only about writing code.
The hardest part is usually understanding the problem clearly enough to build the right solution in the first place.
If requirements are vague, AI simply helps teams generate incorrect implementations faster. If architecture decisions are weak, AI can unintentionally accelerate technical debt. Teams may feel more productive because more code is being produced, but underneath the surface, complexity and maintenance costs continue growing silently.
This is why many senior engineers today are becoming more focused on design quality than raw coding speed.

High-Performing Teams Think Differently About Rework
Interestingly, elite engineering teams do not eliminate rework completely.
They understand that change is a natural part of software development. Requirements evolve, markets shift, users behave unpredictably, and no system design survives reality perfectly.
What strong teams do differently is reduce avoidable rework.
Instead of rushing directly into implementation, they spend more time aligning expectations early. They prototype quickly, validate assumptions sooner, and encourage technical discussions before large-scale development begins. Their goal is not to create endless documentation, but to create enough shared understanding that developers are not constantly rebuilding the same things.
They also design systems with change in mind. Rather than tightly coupling every service together, they prioritize modularity and maintainability because they assume future changes are inevitable. This mindset completely changes how teams approach architecture.
The question becomes:
“How do we make future changes cheaper?”
—not—
“How do we avoid change forever?”
That difference in thinking is huge.

The Business Cost Is Bigger Than Most People Realize
Imagine a 10-person engineering team losing just two hours per day to avoidable rework. That may not sound catastrophic at first, but over weeks and months, the numbers become enormous. Hundreds of engineering hours disappear into fixing preventable issues instead of building real business value.
And the impact is not only financial.
Constant rework slowly damages morale inside teams. Developers become frustrated because they feel like nothing is ever truly finished. Product teams lose confidence in timelines. Technical debt increases pressure on future releases. Eventually, engineering culture shifts from innovation into survival mode, where teams spend more time maintaining instability than creating progress.
This is why weak SDD is not simply a documentation issue.
It’s a scalability issue.
A delivery issue.
A business issue.

Final Thoughts
The software industry loves discussing frameworks, AI tools, productivity hacks, and shipping velocity. But many teams are still ignoring one of the most expensive hidden problems in engineering:
Building the wrong thing correctly is still failure.
And in many cases, teams are not slowed down because developers lack talent. They are slowed down because the organization failed to create enough clarity before implementation began.
Better SDD will never feel as exciting as shipping features quickly. Documentation rarely goes viral on social media. Architecture discussions are not glamorous. But over the long term, the teams that invest in clarity almost always move faster than the teams that constantly rebuild their own mistakes.

Sustainable speed in software engineering does not come from writing code faster.
It comes from reducing the amount of code you need to rewrite later.

Website: https://myspec.dev
Feedback form: https://docs.google.com/forms/d/e/1FAIpQLSfiwMWMqFgUUVXops5J1LWsF7DQOJGUqwBATbtlx8IJ9fma1Q/viewform