The Hidden Costs of Treating Software Development as Assembly-Line Work
I specialize in developing object-oriented java applications that aligns with business objectives, using Domain-Driven Design principles to ensure technical decisions drive tangible value. By focussing on a deep understanding of the business domain, I craft solutions that solve real problems while maximizing ROI. My approach evaluates the cost/profit ratio of every decision—only implementing technologies when the benefits outweigh the costs. I’ve been called in to revive stalled projects and address challenges where others have struggled. My focus is on creating software that not only meets but exceeds business expectations. Whether working with legacy systems or modern frameworks, I select the right technologies to maximize value—not just follow trends. I believe software should be a strategic asset, and this mindset guides every decision I make in development.
Why is Agile no longer agile?
What began as a manifesto for adaptability and learning has become quite the opposite. The language of agility — iteration, feedback, collaboration — still echoes in every stand-up and retrospective, but the meaning has hollowed out. Adaptability and learning have shifted from improving the product to improving the process — and that shift is quietly killing product quality.
We’ve mistaken flow for understanding, velocity for progress, and process optimization for engineering discipline. The result is an industry that’s better than ever at delivering output, but increasingly uncertain about what it’s delivering — or why.
1. The Loss of the Engineering Mindset
Engineering, at its core, is about understanding before building. It’s about modelling reality — seeing how forces interact, how structures hold, and how constraints shape solutions.
In software, that mindset has largely disappeared. In most organizations, “engineers” are handed Jira tickets as if they’re factory instructions: build this, tweak that, close the ticket. Each task is framed as a discrete, local activity, stripped of context.
The problem isn’t the tasks themselves; it’s that the work has been decomposed to the point where no one holds the whole system in mind. Engineers stop reasoning about design, trade-offs, or domain models — they simply execute. And when everyone optimizes locally, the system as a whole drifts toward incoherence. The result: local optimizations, global chaos.
2. Agile as an Industrial Process
Agile was born as a rebellion against heavyweight industrial processes. But ironically, in many organizations, it has evolved into one.
When misunderstood, Agile becomes the very factory model it once tried to escape. Velocity becomes the new production metric. Burndown charts replace architectural blueprints. The stand-up meeting, meant for learning and coordination, becomes a miniature status report.
Iteration turns into throughput. Reflection turns into ceremony. And “agility” — once a mindset of curiosity and adaptation — becomes a synonym for “keep delivering, faster.”
Real engineering values quality, safety, predictability, and understanding. Industrialized Agile values speed, utilization, and measurable output. We’ve optimized the machine, not the mind.
3. The Illusion of Iteration
Iteration has become one of the most misunderstood ideas in modern software. The phrase “we’ll refactor later” sounds agile, but often hides an absence of design.
True iteration isn’t about trial and error — it’s about hypothesis and learning. You build, you observe, you refine — but always within a coherent conceptual model. Each iteration should increase understanding, not just produce code.
Without that underlying model, every sprint is just another random walk through the problem space. The system grows, but comprehension shrinks. We’re moving, but not progressing. Iteration without understanding isn’t agility; it’s entropy with better marketing.
4. Design Thinking Replaced by Delivery Thinking
In mechanical, civil, or electrical engineering, design precedes construction. You don’t “ship and see” how a bridge behaves. You model the load, the materials, the structure — and only then do you build.
Software somehow convinced itself it’s different. We’ve embraced the myth that all mistakes are cheap to fix, that iteration makes foresight obsolete. That may be true for features, but not for foundations.
When the underlying model is wrong, every new feature compounds the error. The product still moves forward — superficially — but each step is heavier than the last. Design thinking has been replaced by delivery thinking: the assumption that as long as we keep shipping, we must be progressing. But output isn’t outcome. And delivery without understanding doesn’t scale — it accumulates.
5. How Specialization Fragmented Ownership
Modern software development has become a study in fragmentation. Frontend developers handle the UI. Backend developers manage the APIs. DevOps engineers ensure deployment pipelines run smoothly. QA tests what arrives at the end.
Each of these roles has grown in depth and sophistication — yet collectively they’ve eroded ownership. No one sees the whole. Each person touches a piece of the elephant and describes a different animal.
We’ve built production pipelines optimized for division of labor, not integration of understanding. The system may look efficient from a management dashboard, but in practice, it’s a collection of specialized silos glued together by Jira tickets. The more specialized the roles, the thinner the shared mental model becomes.
6. The Hidden Costs of Production Thinking
At this point, some might shrug and say: So what?
If production-driven software still ships features and keeps users happy, why worry?
Because what looks like progress in the short term turns into erosion over time.
Software isn’t a factory product — every system is a one-boat race. There’s no second boat to prove how much smoother, faster, or cheaper we could have gone with a coherent design. So the decline goes unnoticed, quarter after quarter, masked by charts and metrics that still appear “green.”
The real costs emerge slowly but relentlessly:
Maintenance explodes. Every change touches code that was never designed to evolve. What once took days now takes weeks. Each sprint adds complexity faster than it removes it.
Team size inflates. Because specialization fragments understanding, coordination overhead grows. Every new feature requires more meetings, more cross-team alignment, more “handoffs.”
Productivity declines. Engineers spend more time deciphering intent than creating value. Decisions become defensive — minimal, local, safe.
Business value collapses. Teams that no longer understand the domain can’t steer toward its goals. Features still ship, but they miss the mark. The product slowly drifts away from the business case it was meant to serve.
In short: costs increase dramatically while delivered value approaches zero.
ROI turns negative not because teams are lazy or management is careless, but because the process itself rewards motion over meaning.
That’s the hidden cost of production thinking: you end up building more and understanding less — until you’ve spent millions delivering something nobody truly wanted.
This risks the view of the IT departments becoming an expensive burden whilst it should be a strategic asset.
7. Rediscovering Engineering
If the hidden costs of production thinking are so steep, what should we measure instead of velocity or output?
The true metric is coherence. Not lines of code shipped, not tickets closed, but the degree to which the system makes sense — to the engineers, to the business, and to the domain it serves.
Can we still explain, without mentioning technology, what we’ve built? Can we describe how the domain actors interact, and how the core domain objects support them? Can we tell, without reading a line of code, which part of the application handles which part of the business domain?
When the answer is yes, you’re doing real engineering. You’ve preserved understanding, maintained alignment with business goals, and created a system that can evolve without collapsing under its own complexity.
Coherence is the bridge between business intent and technical reality. It is the safeguard against endless motion without progress, the anchor that ensures engineering remains a strategic asset rather than a costly burden.
