Engineering Excellence: Why Perfection Is the Wrong Goal
Engineering excellence isn’t about perfection. I see this misconception time and again, especially in larger organisations with multiple teams. There’s this persistent belief that before we can move to a new way of working, we must understand every facet, every choice, every possible outcome. The urge is to make a big, detailed plan, one that covers all the bases before we even take the first step.
But here’s the reality: as soon as you start implementing anything, whether it’s with people, systems, or software, the needs you discover are different from the ones you anticipated at the outset. The plan you so carefully crafted is almost immediately rendered obsolete by the first bit of feedback you receive. That’s not to say planning is pointless. Far from it. We absolutely need planning. But the plan itself, every little detail, is the irrelevant part.
There’s a quote often attributed to Eisenhower: “Plans are irrelevant, but planning is everything.” It’s the act of planning, the discussions, the exploration of options, the sharing of information, that matters. The plan itself? It rarely survives first contact with reality. Sun Tzu said it best: “No plan survives contact with the enemy.” In our world, the “enemy” is the complex, ever-changing nature of software development and organisational change.
If your goal is engineering excellence, stop chasing perfection. Instead, focus on instilling modern software engineering ideas that are, at their core, continuous:
- Continuous delivery
- Continuous quality
- Continuous adaptation
- Continuous learning
It’s this continuous, emergent nature that matters. The knowledge you need, the challenges you’ll face, and the solutions you’ll discover will all emerge over time. Our job is to create a system that adapts as new knowledge emerges, so we can deliver working products and high-quality output. The goal isn’t “agility” for its own sake, but being fast, nimble, and able to deliver for your customers. That’s what agility really means.
Common Barriers to Modern Engineering Practices
Every time I work with customers, we talk about practices that enable this kind of excellence. Take trunk-based development, for example. I was discussing this just yesterday, and the customer immediately listed five or six reasons why it wouldn’t work for them. “We can’t do it that fast,” they said. “Our process is too manual.”
My response is always the same: Why are those things blocking your ability to adopt modern engineering practices? Where did those constraints come from, and how can you fix them? Sometimes, the answer is legacy products or manual infrastructure that will take time to modernise. If you’re still manually building out your infrastructure or have manual steps in your build process, the idea of trunk-based development can seem daunting. The friction is real.
But if you want fast feedback, you have to get to your customers as quickly as possible, with high quality. Delivering rubbish just gets you rubbish feedback. We want to deliver high-quality, usable, working product continuously, as quickly and as often as possible.
What You Need for Engineering Excellence
To achieve this, you need a few foundational capabilities:
- Clean code: You can’t move fast with poor quality code. If you’re starting with a mess, that’s your first area to address.
- Observability: You need to see what’s happening in your system, both from a user perspective and internally. If you don’t have telemetry or observability, you’re flying blind.
- CI/CD (Continuous Integration/Continuous Delivery): Automate your build and deployment processes. Manual steps are friction.
- Automated testing: The more you can test automatically, the faster you can get feedback. Long-running, manual, or brittle tests are a bottleneck.
Think of it like the tracking on your car. If your wheels are even slightly misaligned, your tyres wear out faster, costing you more money in the long run. Pay a little now to fix the alignment, and your tyres last much longer. The same is true for your software. Fix the “tracking”, clean up your code, add observability, automate your builds and tests, and you’ll go further, faster, and with less pain.
A Real-World Example: Azure DevOps
Let me give you a concrete example. The Azure DevOps team started with a massive legacy product. The code quality was, by their own admission, not great. Testing was mostly long-running system tests, think Selenium, but with their own system. It took 48 to 72 hours to run the full test suite. That’s simply not good enough. If it takes that long to find out you’ve broken something, the developer has lost context and has to relearn everything, wasting massive cognitive effort.
So, what did they do? They chipped away at the problem, sprint by sprint, over four years, about 80 sprints. They paid back a little technical debt each time. The result? They went from 48-72 hours to just three and a half minutes to run the entire test suite, including a full environment and integration tests, on a developer’s local machine. That’s the power of shortening feedback loops.
Shortening Feedback Loops: The Heart of Agile and DevOps
This is the fundamental premise of both DevOps and Agile: shorten the feedback loops.
- DevOps: Shortens feedback loops in engineering.
- Agile: Shortens feedback loops in business.
If you want your teams to build better and deliver faster, start with engineering excellence. Not perfection. Not a grand, unchangeable plan. But a system that continuously adapts, learns, and improves. That’s how you deliver real value to your customers, and that’s what true agility looks like.
Meta Description:
Discover why engineering excellence isn’t about perfection, but about continuous improvement, clean code, and shortening feedback loops. Learn how to overcome common barriers and deliver real value with modern Agile and DevOps practices.