Quality often becomes the last thing on our minds, both for individuals and companies, even though we swear to value it. Why? Because quality can feel dull, complex, and time-consuming.
As software engineers, we really enjoy building new features and cleaning up our code, but honestly, not many of us can get happy about writing tests or dealing with bugs. And even having powerful AI tools in our toolbelt, we still tend to skip the tiresome parts.
Over and over again, I’ve seen engineers rejecting bugs because they seemed “non-critical” or because the original reporter went off, so the issue obviously “fixed itself,” right? We ignore coverage metrics and carry on, hoping nobody notices. And often, it takes someone from the top or an external powerful enforcer to set up standards and make us do the right thing.
What Does “Quality” Really Mean?
But what exactly is “quality,” and why do we struggle to agree on it? The truth is that each of us sees quality through our own lens, and in many contexts, we can all be “right.”
Let’s take a look at some historical examples to see just how different things can be!
RAF Aerial Bomb Quality Control.
When WWII is started, Britain’s bombs were pretty unreliable, with about 40% of them failing to go off. It was mainly because of some faulty fuses and issues with how they were made.
By 1943, they used some pretty clever tools for putting together fuses, like precision jigs, and they got smart with testing too, using statistical sampling and test drops.
They also had these go/no-go gauges and did daily checks on the production line. All this helped cut down the fail rates to under 10%, which really improved the reliability of the bombs.
NASA and FMEA.
On January 27, 1967, a fire in the Apollo 1 cabin during a ground test tragically took the lives of all three astronauts. After looking into what went wrong, investigators found a ton of potential issues with the electrical wiring, materials, and procedures.
NASA implemented Failure Mode and Effects Analysis (FMEA) and increased inspections of their suppliers for all components, including life-support hoses and circuit breakers. They listed potential failures, rated their severity and likelihood, and then adjusted the designs or procedures to address the issues. Does it look like bug tracking?
Quality as a Mindset
From these stories, it’s clear that quality isn’t just bug fixes, writing tests, or doing code reviews. Quality measures how well our product meets and exceeds, our customers’ expectations. But how can a single engineer in a development team truly understand those expectations?
“If I were given one hour to save the planet, I would spend 59 minutes defining the problem…” — Albert Einstein
Imagine a small healthcare startup whose mission is to automate life-saving prescriptions for heart-attack patients. In their rush to deploy new features, a bug sneaks into production. Suddenly, dozens of patients receive incorrect prescriptions, severely affecting their health and safety. Isn’t that as catastrophic as a bomb explosion on the factory line?
Quality isn’t simple — it’s a mindset.
It’s all about:
- Getting to know our users and what they really need;
- Taking responsibility for the real-world impact of our software.
- When we move from “just ship it” to “ship it right,” we make quality a priority instead of an afterthought.
Everyone’s Responsibility
By shifting quality left, we move all quality-related activities into the earliest stages of the software delivery lifecycle. As a mantra, we should do everything necessary to meet the customer expectations that truly matter. From the very first idea to the moment code reaches production, multiple teams and individuals share responsibility here:
- Product managers ensure if we’re solving the right problem.
- UX designers make the solution intuitive and accessible.
- Engineers implement changes thoughtfully, write tests, raise concerns, and avoid blindly following orders.
- Support teams step in whenever a defect slips through, helping our users and restoring their confidence.
It’s a long journey from concept to deployment, and every role plays a critical part — because quality is everyone’s business. This approach can be summed up as prevention over detection.
My Last Shout-out!
Finally, a shout-out to your QA engineers — they’re not there just to slow down your delivery 😉. They should focus on solving problems every day rather than going throigh the morning task list.
True quality engineers design and implement quality controls, conduct audits, measures the costs tied to quality (both the wins and the risks), capture the data needed for smart decisions.
Give them the freedom, they will give your product the future.
Thanks for reading!
Original post: https://rufat-khaslarov.medium.com/next-time-you-think-quality-is-optional-stop-and-read-this-before-its-too-late-cca7beed8bc7
❤️ If you enjoyed this post, you can buy me a coffee: ☕️ Buy me a coffee
Top comments (0)