Home Blog

The Dangerous Fantasy of Zero-Defect Software

The notion of “zero-defect” software deserves to be filed alongside perpetual motion machines, flat earth cosmologies, and politicians’ promises of transparency. It is a belief clung to with the fervor of a religious conviction, despite decades of evidence to the contrary.

One is tempted to admire its simplicity. Who wouldn’t want immaculate software, untainted by bugs, glitches, or the occasional crash? But only the very naïve (or the very pompous) believe it’s possible. In truth, the dream of flawless code is a myth sustained by managerial vanity and technical illiteracy, not by science or practice.

The Misconception

Enter the fabled “I Am Spartacus” moment. The scene is always the same: the final days before release, nerves taut, deadlines looming. A middle manager, swollen with borrowed conviction, thunders:

“I will not sign off until there are zero defects!”

How stirring. How cinematic. And how utterly stupid.

This isn’t moral courage; it’s theatre. What it reveals is not a principled stand, but a fundamental misunderstanding of software itself, akin to demanding an author publish only when every possible typo, misprint, and future misinterpretation has been eradicated.

The Reality of Testing

Fred Brooks spelled it out in The Mythical Man-Month: past a certain point, every bug fixed risks hatching new ones. Complexity is not tamed by human willpower; it multiplies under it.

Even Steve Jobs, a man not known for his tolerance of imperfection, acknowledged as much at Apple’s 1997 WWDC. If Jobs could admit to the inevitability of software flaws, what business does a cubicle Caesar have in insisting otherwise?

Look Around You

Do you own a smart phone? Then you own a monument to this truth. Apple, Samsung, Microsoft, these empires release products crawling with known bugs. And yet, people buy them by the billion. Why? Because the software works well enough for its purpose, and the defects are patched later.

Imagine if Bill Gates had once said: “We shall not release Windows until it is flawless.” You would still be waiting for Windows 95, and your office would still be filled with typewriters.

The Poison of “Zero Defects”

The most pernicious quality of this delusion is not its absurdity but its toxicity. Once the “zero defects” gauntlet is thrown, it becomes politically impossible to withdraw it. The loudmouth who made the pronouncement must either stand by it (at great cost of time, money, and morale) or suffer the humiliation of backpedaling.

And so projects stall, tempers flare, and credibility is squandered. Like any cult, the demand for purity ends in ruin.

A Rational Alternative

There is, mercifully, a grown-up approach:

  • Define exit criteria before the hysteria begins.

  • Recognize real constraints; time, money, risk.

  • Reject absolutism and aim instead for fitness to purpose.

As the Google Testing blog often illustrates, intelligent testing is about managing risk, not eradicating imperfection.

The Takeaway Is This

What sustains the zero-defect myth is not logic but vanity. Humans crave the fantasy of control, the mirage of perfection. They would rather posture than confront reality.

If you must deal with such a zealot, I recommend relocating the debate to a bar. There, lubricated by whiskey, even the most deluded manager might concede that “bug-free” is a phrase best left to insecticide commercials. And if not? Then drink alone, by all accounts, that’s when the magic starts.

The Expert is not the Best Project Manager

Corporate folklore holds that the surest way to find a project manager is to trawl the aquarium for the fattest subject-matter fish. Whoever knows the most about the content, runs the lore, must surely be the best to run the project. This is wrong in the same way that Instagram influencers’ “science” is wrong: it confuses adornment with aerodynamics.

Seasoned project managers know the ritual. You’re vetted by an intermediary whose first sacramental question is, “Do you have experience with System XYZ?” Answer “No,” and the catechism concludes: “Too bad—client insists on deep XYZ expertise.” Your history of delivering complex efforts on time and budget is waved away. Content is king; competence is court jester.

Consider the farce as it would look in any other arena. You’re hiring someone to organize a rock festival. The decisive criterion? Not whether they can plan logistics, wrangle suppliers, manage risk, and keep 50,000 humans watered, fed, and untrampled—but whether they can play lead guitar and recite Metallica’s back catalog. That they have already staged jazz, film, and food-truck festivals with aplomb counts for little. If they can’t shred, they can’t shepherd.

Thus does expertise in the product masquerade as expertise in the process.

Appointing a project manager on content alone is selecting the right man for the wrong job—and then blaming him when he does the job he was selected for. You have, in effect, hired a fan to run security.

Two pathologies follow. First, conflict of interest. A project manager’s cardinal duty is adjudication: trading scope against time against money, and doing so without emotional attachment to any single feature. The domain obsessive—our rock purist—will be tempted to spend the medical tent on an extra band, because the music moves him more than the ambulance does. Affection is not governance.

Second, loss of altitude. The subject-matter manager cannot help plunging into the weeds, second-guessing the very specialists they hired. They meddle because they know, and because knowing feels like managing. Meanwhile, the real work—forecasting cost, policing risk, sequencing dependencies, choreographing change—goes malnourished. 

These are the project managers who brief the Steering Committee with breathless technical minutiae about a change request, yet cannot produce an up-to-date cost forecast, a living risk profile, or the mitigations that make unpleasant surprises merely expensive rather than fatal.

Put differently: they’re backstage tuning guitars and arguing over the set list while no one is erecting the ticket booths, stocking the concessions, or ensuring that the toilets, those unglamorous guarantors of civilization, actually function. The music may be sublime; the festival will still fail.

The remedy is drearily adult. Hire project managers for the thing they do: impose structure, price risk, arbitrate trade-offs, and keep promises. Let experts be experts, accountable for outputs within their craft. Demand of the project lead not devotion to a domain but fidelity to delivery. If you must worship something, worship the schedule and the balance sheet; they, unlike taste, can be audited.

Otherwise, by all means keep privileging virtuosity over vigilance. Just don’t feign astonishment when the solos soar and the crowd stampedes. 

Far out!

Yes, literally.

– Photo by Kacper Cybinski from Pexels

The Business Case: Vows Made, Vows Broken

The business case is not the drab prologue to a budget request. It is (at least in theory) a solemn vow. It declares why a project exists, what it promises, and how it justifies the sacrifice of time, money, and human patience. But like most vows, it is made with great ceremony and then almost immediately forgotten.

Projects that began with noble intentions drift into fiasco not because they were conceived badly, but because their “vows” are treated as decorative. The business case, embalmed in a SharePoint vault, becomes a relic, consulted only in moments of panic, never as the governing principle it should be.

Vows at the Altar

At a wedding, the couple exchange vows; benefits (companionship, pooled Netflix subscriptions), costs (mortgages, tuition fees), and risks (in-laws, entropy). With foolish optimism, they say “I do.”

But vows that aren’t revisited degrade into wishful thinking. The same holds true for projects. Launch without revisiting the business case, and you’re not on a heroic journey, you’re staggering blindfolded toward divorce court. If you doubt the comparison, listen to relationship expert Esther Perel’s talk on Wedding Vows

A Living Instrument

The business case is not scripture carved in stone; it is a living instrument. Every adjustment (funding, headcount, equipment, facilities) must be interrogated against it:

    • Do we still get the promised benefits?

    • What new risks have we just invited in?

    • Are our resources sufficient, or are we mortgaging tomorrow?

    • What fresh damage have we done to time and cost?

If you can’t answer these, you’re not steering a project. You’re drifting.

How Projects Really Go Off Course

Most projects do not die spectacular deaths; they suffocate slowly. Two killers are most common:

    1. Negligence: Scope creep: the slow accretion of “just one more feature.” It’s managerial cowardice disguised as flexibility.

    2. Change Requests (CRs): These are the most lethal because they wear a halo of legitimacy. A single badly judged CR can destabilize the entire project. A dozen “minor” ones can bleed it to death.

Need proof? Look no further than the Berlin Brandenburg Airport fiasco, where “formal processes” produced chaos on a national stage.

The Discipline to Stay Aligned

Avoiding this drift requires a discipline most organizations lack:

    • Make the business case your liturgy. Begin and end every decision with it.

    • Define thresholds. Know what scale of deviation demands a pause, pivot, or termination.

    • Track cumulative impact. Scope creep kills by paper cuts. Count them.

    • Re-test assumptions. Markets move faster than steering committees.

    • Escalate ruthlessly. If the vow no longer holds, end the marriage.

For those who need their medicine with less sarcasm, consult PMI’s Benefits Realization Guide.

The Hard Truth

Sometimes the bravest decision is not “rebaseline,” or “phase two,” or “absorbing the change.” Sometimes the only rational word left is “no.” When the business case is dead, continuing is not project management, it’s necrophilia. The sunk cost fallacy is not a strategy; it’s an obituary. 

And So…

The business case is your vow. Treat it as a relic, and the project will end in bitter recrimination. Treat it as living, and you stand a chance of delivery, if not bliss, then at least survival. But do not delude yourself: projects are not fairy tales. They are arranged marriages, held together not by romance but by discipline. The happy ending, if you get one, comes only to those who revisit their vows.

A Project Schedule is not a Project Plan

L

et us begin with a heresy so obvious it will strike some as revelation: your beloved MS Project file is not a project plan. Neither is any other Gantt-bedizened liturgy of bars and dates. It is not the droning procession of activities, milestones, and dependencies that will save you from your own wishful thinking.

Time and again, when one asks the perfectly straightforward question—May I see your project plan?—what arrives, with the air of a conjurer unveiling Excalibur, is an .mpp file. If we had a coin for each time this happened, we would not be millionaires; we would merely dine better, which in our experience is a far more reliable measure of human progress.

Yes, an MS Project schedule can be impressive in its way. A hinge-point here, a dependency there, resources assigned with the precision of a Swiss watchmaker. Some go so far as to break down phases into sub-phases, activities into sub-activities, until the thing resembles a never-ending pattern of managerial anxiety. It is, at its best, a delicate piece of filigree. And, like filigree, largely ornamental—particularly to the majority who cannot even open it, condemned as they are to squint at a pixelated screenshot in a slide deck and pretend comprehension.

But no matter how grand the fresco or how fine the brushwork, it remains what it is: a schedule. It is still not a plan. Repeat after me, with staccato emphasis for those in the back: it. is. not. a. plan.

If we were to plan a bank robbery—and I do not recommend it, though the metaphor is serviceable—we might indeed decide who digs the tunnel, who cuts the alarm, which drill bites best through the safe, and how much time we have before the getaway car must depart. This is choreography. It may even be good choreography. But it is not strategy. It is not governance. It is not control.

The Project Management Body of Knowledge, not a volume to inflame the senses but occasionally sound on first principles, defines a project plan as “a formal, approved document used to guide both project execution and project control.” Please linger a moment on those last two words. A plan is not merely a roster of tasks and a calendar with delusions. The activities will change; the dates will slip; the people you are relying on will, being human, err. The plan is the system by which you intend to remain in charge of reality when reality declines to obey your spreadsheet.

Where is your governance model? How will you manage risk when it ceases to be hypothetical? What is your change control when change becomes the only constant? Where are the issue pathways, the escalation ladders, the communications regime that tells the right truth to the right people at the right time? Who decides, and what do they decide, and by what criteria, when the elegant latticework of your schedule meets the indifferent brutality of events?

Return, if you like, to our bank job. What do we do when the headcount is higher than expected? Do we triage the vulnerable or let the old teller die because he is inconvenient to the plan? Who assumes command when the appointed lead goes down under the flab-to-firearm zeal of an overeager security guard? What is the line we shall speak to the authorities when captured, and who is authorized to speak it? If you cannot answer these questions, you are not planning. You are daydreaming.

This, incidentally, is why the beloved television series—La Casa de Papel for the binge-watching classes—captured imaginations. The Professor is not impressive because he can read a floorplan. He is impressive because he imagines failure states, inventorying the unknowns with morbid tenderness, and installs mechanisms of response: contingencies, countermeasures, doctrine. In other words, he has a plan. He has anticipated the moment when the plan fails—and planned for that too.

A real project plan is the architecture of foresight. It lays out who decides and how, what risks justify preemption and which tolerate delay, what changes are admissible and what triggers a reset, who needs to know what and when. It is the constitution of the enterprise, not the parade schedule.

By all means, keep your schedules. They are useful, as timetables are useful. But do not confuse the railway clock with the locomotive, let alone the track. If you wish to be something more than the victim of your own chart, build the apparatus of control: governance, risk, change, issue, and communication management. Then, and only then, may your glittering grid of dates aspire to be part of a plan rather than a calendar with pretensions.

– Photo by Jens Johnsson from Pexels

The Piety of “On Time and On Budget”

On time and on budget sounds like discipline; in practice, it often certifies luck. When punctuality and thrift are treated as the whole of performance, coincidence is misread as competence and the organization learns the wrong lesson.

Yes, a team can, by Forrest-Gump serendipity, hit the date and the number. That proves a calendar was met and a ledger balanced, not that the right thing was built the right way. In cinema, luck is charming; in management, elevating luck to evidence is an epistemic failure because it rewards the appearance of control over the substance of value.

How the Slogan Shrunk the Goal

The phrase began as shorthand for balanced delivery; right thing, right way, right cost, right time. Taken literally, it amputates what makes the effort worthwhile:

    • Scope: Did we deliver the thing we promised, not just something with the same label?

    • Quality: Is it usable, reliable, and safe (or merely demo-able)?

When these vanish, organizations celebrate counterfeits: features kicked to “phase two,” quality shaved to meet a date, defects deferred like unsecured debt. (For a classic warning, read Brooks’s The Mythical Man-Month.)

Why Smart People Keep Falling for It

This narrow success frame persists because it produces flattering illusions:

    1. False positives: Punctual mediocrity passes as victory.

    2. Cosmetic control: Gantt charts behave even while risks go unmanaged.

    3. Perverse incentives: Worship a metric; get rituals, not results.

Software teams learned this the hard way, which is why they track lead time, deployment frequency, change-failure rate, and mean time to restore; signals that outcomes, not optics, are improving.

What Competence Actually Requires

Real management solves a system of equations, not a single constraint. Judge performance across multiple dimensions and accept that trade-offs are inevitable:

    1. Time & Cost (necessary, never sufficient).

    2. Scope (completeness and intent, not scope creep by stealth).

    3. Quality (defects, reliability, usability).

    4. Benefits (adoption and activation now; revenue and cost-to-serve later).

    5. Risk (which hazards we reduced, accepted, or created).

    6. Stakeholders (expectations met, not just signatures collected).

The adult distinction is between disciplined trade-offs (explicit, justified, transparently governed) and undisciplined slippage (quiet cuts and quiet hopes).

A Better Instrument: Scorecard, Not Slogan

Replace the bumper sticker with a compact scorecard that makes trade-offs visible and auditable:

    • Baseline vs. Actual Time/Cost: facts over boasts.

    • Planned vs. Achieved Scope: no euphemisms.

    • Quality Outcomes: escaped defects, uptime/SLOs, usability thresholds.

    • Benefits Realization: leading (usage, activation) and lagging (unit economics).

    • Risk Posture: open risks, mitigations, residual exposure.

    • Stakeholder Signals: satisfaction deltas, not vanity NPS.

Evaluate the how (governance, risk management, change control) alongside the what (measurable outcomes). If this feels unfamiliar, start with Kaplan & Norton’s Harvard Business Review classic, The Balanced Scorecard – Measures That Drive Performance.

Conclusion: Retire the Small God

A project can miss its first date or budget and still be exemplary if it delivers the right scope at durable quality, realizes benefits, and manages risk openly. But a project that hits date and dollar while hollowing out everything else is not a success, it’s a liability with good manners. If “on time and on budget” is your whole liturgy, you’re grading chance and calling it leadership. Raise the standard; measure what matters.

Contingency Budget Should Reflect Risks

Isn’t it curious—by which we mean ludicrous—that more than half the projects on this planet stagger forth with precisely the same contingency budget, as if fate itself had standardized its malice? Risks differ, contexts vary, suppliers wobble, currencies sulk, and yet the priesthood assures us that one charm repels all demons.

Every tribe has its talisman. In childhood it was mother’s kiss: a sacrament applied to a scraped knee with miraculous results. On the football pitch—soccer, if you must—the anointed object is the damp sponge. A man writhes as though auditioning for the Last Rites; a sponge is dabbed; Lazarus sprints.

Projects have their own sponge. It goes by “contingency” or “tolerance,” depending on which catechism you recite. And—here is the true enchantment—it is always ten percent. Not eight, not fifteen. Ten. The digits march like Roman soldiers: And. It. Is. Always. Ten. Percent.

This, in a sane world, would be the point at which someone asks whether the margin of error might have something to do with reality. With how well we know the domain. With the volatility of prices, the fragility of suppliers, the novelty of the technology, the competence (or absence) of the team, the brutality of the schedule. But no: bring forth the silver bullet that fits every caliber.

Why ten? Nobody knows, and—more damning—nobody seems embarrassed not to know. Perhaps, in some ancestral spreadsheet, ten percent was a defensible hedge for one specific undertaking. Perhaps a standards committee embalmed it, and the embalming fluid spread across the corporate bloodstream. Or perhaps it diffused the way all superstitions do: because it was tidy, repeatable, and made the anxious feel insured against the weather.

Whatever the origin, the effect is the same. A risk unpriced is a risk unmanaged, and a risk priced by numerology is managed by nobody. 

The adult alternative is not mystical: quantify uncertainties, model ranges, revisit as information improves, and fund the consequences. Some projects deserve two percent; others, twenty and a prayer. Only a cult would insist they all merit the same tithe.

But then, magic has its consolations. You don’t have to think; you don’t have to argue; you don’t have to tell the Steering Committee that the gods may be angry and that appeasement will cost more than a round number. You can intone “ten percent” and pass the peace.

As with all talismans, the power is in the believer, not the object. And as with all talismans, reality eventually intrudes.