Category: Delivery

  • The Zero-Defect Myth: Stop Chasing Perfection

    The Zero-Defect Myth: Stop Chasing Perfection

    There’s an unspoken agreement in every software team: we all nod along when someone says, “Of course, no software is perfect.”
    And then…

    The first post-release bug hits production.
    Stakeholders panic.
    Customers complain.
    Suddenly, every bug is a five-alarm fire, and the “Can we fix this immediately?” messages start popping up.

    It’s like we know perfection is impossible but God help you if something slips through.

    As Kevlin Henney wisely puts it:

    “If you think good architecture is expensive, try bad architecture.”

    Today, we’re going to call out the myth for what it is, a polite fiction, and unpack why treating every tiny flaw like a crisis is the fastest way to demoralise your team, delay your product, and ironically, introduce more bugs.

    The Zero-Defect Lie We Tell Ourselves

    Let’s be honest: the idea of zero-defect software has never survived contact with reality.
    But that doesn’t stop anyone from believing in it.

    Why Do We Keep Believing?

    • Stakeholders Want Guarantees:
      Their budgets, deadlines, and reputations are riding on this. A flawless release feels like the safest bet.
    • Engineers Want Craftsmanship:
      No dev wants to leave behind spaghetti code or a glaring bug in production. We take pride in our work.
    • Customers Expect Magic:
      Software is invisible. Users don’t see the hours spent testing, debugging, and monitoring.
      They only see when it breaks.

    But Here’s the Thing:

    Software is chaos.

    You’re juggling:

    • Browsers, APIs, legacy systems no one understands.
    • Time zones, hardware quirks, weird network glitches.
    • Last-minute requirement changes.
    • And humans. Unpredictable humans.

    There is no such thing as zero-defect software.
    It’s not just hard, it’s damaging to pretend otherwise.

    What Happens When Everything Feels Like a Fire?

    Let’s zoom in.
    What actually happens when every bug is treated like it’s mission-critical?

    🚨 Everything Feels Like a Crisis

    When every defect is a “P0,” nothing is.
    Teams panic over cosmetic typos like they’re catastrophic outages.
    This leads to:

    • Constant interruptions.
    • Broken focus.
    • Decision fatigue.

    You’re no longer building software, you’re putting out fires full-time.

    🐢 Delivery Slows to a Crawl

    Endless bug triage means features get sidelined.
    Stakeholders start asking, “What’s taking so long?”
    Meanwhile, customers get impatient waiting for actual value, not just minor polish.

    🤯 Morale Tanks

    Fixing low-impact bugs under intense pressure is draining.
    Engineers feel like hamsters on a wheel, never shipping, never done, never good enough.

    And the kicker?
    High churn leads to more bugs, not fewer.

    The False Comfort of Perfectionism

    There’s comfort in thinking, “If we just work harder, test more, double-check everything, maybe this time we’ll get it perfect.”

    Spoiler: you won’t.

    The reality is, systems grow, requirements change, and the next release will always introduce something unexpected.

    Kent Beck, creator of Extreme Programming, put it plainly:

    “Make it work, make it right, make it fast.”

    But let’s be honest “right” doesn’t mean flawless.
    It means right enough.

    Reframing the Quality Conversation: Good Enough > Perfect

    So, how do you escape the zero-defect death spiral?

    1. Prioritise Bugs by Impact, Not Emotion

    Not all bugs are created equal:

    • Does it block users from completing key actions? Fix ASAP.
    • Is it a visual glitch no one’s noticed? Schedule it.
    • Edge case reported by one person out of 10,000? Maybe… leave it.

    2. Define Acceptable Risk Together

    Set the tone before the fires start:

    • Agree on what a P0, P1, P2 really means.
    • Share real-world examples.
    • Remind everyone: shipping faster with minor bugs is often better than endlessly polishing.

    3. Differentiate Release Types

    Not every release needs to be treated like a space shuttle launch:

    • MVP? You’ll fix as you learn.
    • Internal tool? Lower stakes.
    • Mission-critical core feature? Okay, double down on testing, but still, perfection is off the table.

    Stakeholders Will Still Panic

    No matter how much sense this makes, there will always be that one stakeholder who treats every issue like it’s life or death.

    That’s where clear communication, transparency, and triage discipline come in.

    You can’t control the chaos, but you can control how your team responds to it.

    Conclusion

    Zero-defect software isn’t a goal, it’s a mirage.

    The faster you stop chasing perfection, the faster you can focus on what actually matters:

    • Delivering value.
    • Managing risk.
    • Keeping your team sane and productive.

    Remember:
    Perfection is a story we tell ourselves.
    Reliability, trust, and adaptability are what win in the real world.

    References

    • Henney, Kevlin. Presentation: “Software Architecture: The Hard Parts”, 2021.
    • Beck, Kent. Extreme Programming Explained. Addison-Wesley, 2000.
    • Newport, Cal. Deep Work: Rules for Focused Success in a Distracted World. Grand Central Publishing, 2016.

  • AT THE MOUNTAINS OF UNCERTAINTY

    AT THE MOUNTAINS OF UNCERTAINTY

    If you are distressed by anything external, the pain is not due to the thing itself, but to your estimate of it; and this you have the power to revoke at any moment.

    Marcus Aurelius

    Your eyes are locked on the screen. You know this isn’t real, but to your body it may as well be… Thankfully, the film is about to end. Now, if only your amygdala knew this.

    When you can’t see what’s hiding in the dark, your mind imagines the worst. Fleeting glimpses of something horrible. But this hidden terror, could be just a cat rustling through the bushes.

    Any monster, once revealed, loses some of its power. Film directors use this to play with the senses. They don’t show the threat. The keep us guessing, building the tension continuously.
    This works because fear of the unknown is hardwired in all of us. A long time ago, staying alive often meant not finding out what that sound was.

    No plan survives first contact with the enemy.

    Helmuth von Moltke the Elder

    In unknown situations, our survival instincts kick in. We try to gain control to feel safe. But that’s the flaw in our plans: we can’t control everything.

    Old models, like Waterfall, assume everything is known from the start. That we can see the whole path from the top of the hill to the bottom. Real life, especially if in complex domains, rarely works that way.

    This is why “Responding to change over following a plan” is so powerful. It spins the old assumption on its head. We need to accept that we can’t know everything, and move forward anyway.

    Courage is not the absence of fear. It’s the ability to act despite it.

    Being brave doesn’t mean we should jump head first without checking. We need to be smart, removing the risks by not leaving dark places that “monsters” can hide in. And short iterations are great at doing that. We either deliver, or find out why we didn’t. The quicker we reach one of these outcomes, the better we can prepare for the next one.

    After all, we’re here to solve a problem, not to just put some pixels on a screen.

    Ask:

    • How important is this problem to solve?
    • What happens if we don’t?
    • How much time are we willing to spend on this? A week? A year?

    Parkinson’s law says:

    “Work expands to fill the time available for its completion.”

    Which can also be used to our benefit. If we only have 2 days to build a shelter, we should think be thinking of huts, not castles.

    Yes, a castle would be amazing. But what’s the point of how many fireplaces it’s going to have, if we can’t deliver it in the first place? (and this assumes that we actually know how to build a castle already)

    So start with something small. Test the foundation. Fix problems. Iterate.

    And that backlog? Clear it. Those 237 “must-have” features from 2019? We won’t be building them. The team has changed. The market has shifted. Our understanding has evolved.

    So we’ll have some unknowns, so be it. We’ll figure this out.

    references

    Photo by Neil Rosenstech on Unsplash

  • “How long will this take?”

    “How long will this take?”

    The dreaded question. The one that no team wants to answer.

    People think this question is about time. It’s not.

    The currency of estimates are confidence & trust. And this is how your answer is measured.

    (more…)