Fear of Low-Quality Software

Every time I ship a feature, there is a moment after the terminal says build passed where a small voice asks: does it work, or does it just build?

I have been writing software long enough to know the difference between those two. Tests can pass on something that fails people. A demo can impress a room and still hide a bug that waits for someone's real data on someone's real Tuesday.

That voice got louder over the past two years. My caution has nothing to do with caring less. The machines now write more code than any of us can read, and shipping fast stopped being the hard part.

So this is a post about a feeling engineering rarely admits out loud: the fear of low-quality software. Where it comes from, when it is rational, and what I think it is asking of us.

1. The fear has a shape

The fear is not that the code is ugly. Ugly code that runs correctly is fine; plenty of beautiful code has taken systems down with it.

The fear is quieter. It is the suspicion that somewhere in the pile of lines we merged this week there is a branch nobody exercised, an alert firing into a dead channel, a timeout tuned for the happy path, a retry loop quietly doubling a bill. It works in staging, and it fails later, when the cost of failing is highest.

You cannot grep for the code you did not read. That is what makes quality different from almost any other engineering property: its absence is invisible right up until it becomes spectacular.

2. A Friday morning in July 2024

On July 19, 2024, a single content update from CrowdStrike crashed millions of Windows machines within hours.

Hospitals postponed procedures and airlines grounded fleets. Stores could not take payments. The U.S. Government Accountability Office analyzed the aftermath and described how gaps in software testing, supply-chain risk management and contingency planning turned one bad update into a global event.

No attacker was involved. No dramatic fault in ten thousand files of legacy code. An ordinary release moved through an ordinary pipeline on a Friday morning, and the blast radius was planetary.

That is why this fear is rational. Quality failures at scale rarely look like catastrophes while they form. They look like routine.

3. The same fear, closer to the skin

The CrowdStrike outage made headlines because everyone saw it. Medical-device software usually stays out of the news, so the FDA keeps a quieter, more uncomfortable ledger.

A 2025 safety correction on Dexcom's G7 and ONE+ apps describes how a missed sensor-failure alert could delay treatment for a person relying on a continuous glucose monitor. Separate safety communications cover documented cybersecurity vulnerabilities in Contec and Epsimed patient monitors, with corrective actions still working through the field. There is standing FDA guidance on cybersecurity in medical devices, updated in June 2025, because this became a permanent category of risk.

Notice how those documents choose their verbs. A missed alert could delay treatment. Certain monitors could expose data or fail open. Potential is the operative word, and the agencies hold a hard line between potential and proven.

I respect that line and this post keeps it too. But someone's parent wears that sensor. Someone's child is wired to that monitor. For them, the difference between demonstrated and potential is a filing category, not a comfort.

4. We generate code faster than we vouch for it

Into that setting, add the newest variable. AI can draft a module in the time it takes to describe it. It can spin up a service or patch an old bug while the coffee is still hot.

The bottleneck of software used to be writing. It is now deciding what to trust.

A pull request that took two days takes two minutes, and nothing about our appetite for verification scaled to match. Reviews get shorter. Tests increasingly get written after the fact, sometimes by the same model that wrote the product code, quietly grading its own homework.

The demo trap got easier to fall into as well. When a screen can be conjured in an afternoon, the question stops being whether we can build it. The question that matters is what happens the first time a real person brings real mess to a system that has only ever seen the happy path.

I use these tools every day and I refuse to cast them as the villain. They are leverage. Leverage amplifies whatever you already have, including the gaps.

5. What fear is good for

Fear, used well, is attention with a deadline.

The practical shape of it is unglamorous. Tests around the risky paths, written by someone who expects them to catch nothing at first. Releases that go out in stages, so a mistake meets a hundred users before it meets a million. A named person owning what the system may touch and what happens when it fails. The readiness to say not yet, this one is not ready.

None of that is red tape. All of it costs less than an apology. And every item on the list works the same in a world where the first draft comes from a model.

Which brings me to the point I actually want to make. Fear of low-quality software should not make us timid. It should make us deliberate.

6. Quality is not the enemy of speed

I don't want this to become an argument for slowing everything down, adding unnecessary bureaucracy, or returning to a world where shipping a feature takes six months.

That would miss the point.

The tools we have today are remarkable. AI-assisted development, reusable components, automated testing, continuous delivery, and better infrastructure give us opportunities to build software that is both faster to deliver and more reliable.

But we need to use that speed intelligently.

If AI helps us produce code five times faster, we should also invest in better ways to review, test, and validate that code.

If we can launch an MVP in weeks instead of months, we should be equally deliberate about what that MVP is allowed to do, what risks it introduces, and how we will respond if it fails.

If we can reduce development costs, we should use some of those savings to improve the quality of what we ship.

And if a system becomes critical to people's lives, we must be willing to invest accordingly.

There is no universal amount of testing or engineering effort that guarantees safety. Every system has different risks, constraints, and failure modes. But there is a meaningful difference between accepting a risk after understanding it and accepting it because nobody bothered to look.

That difference is responsibility.

Final thoughts: Build things people can trust

I remain genuinely excited about software engineering.

I believe we're entering a period where smaller teams can solve bigger problems, where new ideas can reach people faster, and where technology can improve the quality of life in ways that were difficult to imagine just a few years ago.

I don't want fear to prevent us from building.

I want it to make us better at building.

Because behind every application is a person who trusts it to do something. Someone who expects their money to arrive, their information to remain private, their equipment to operate correctly, or their medical device to alert them when something is wrong.

Those people don't care how quickly we generated the code. They don't care how impressive the demo looked or how many story points we completed.

They care whether the software does what it promises.

And that trust is earned through the decisions we make long before the product reaches them.

We should absolutely keep building faster. But we must never confuse the ability to ship software with the responsibility to ship software that deserves to be trusted.

Because sometimes, software quality isn't just about a better product.

Sometimes, it's about someone's life.