Dear Reader, let's talk about quality.
👉 When you want to achieve quality, you need to focus on quantity.
That might sound counterintuitive at first. But imagine this: you're doing something just once. And because it’s the only time you do it, you try to perfect it. You pour days, maybe weeks, into polishing this one thing. Every detail is scrutinized. Every decision feels like it matters more than it should.
But here’s the problem: if you've only done this one thing once, how do you know what "perfect" even looks like? You've never tried a different approach. You haven't seen how others do it. You're working in a vacuum.
Now, contrast that with a mindset of iteration.
As a side note, a study published in Frontiers in Psychology examined the “equal-odds rule,” which suggests that the probability of producing a masterpiece is proportional to the total number of works created. The research found that individuals who generated more ideas also produced higher-quality, original ideas, supporting the notion that quantity can lead to quality. 12
You build, you ship, you reflect, and you try again. And again. Every day, you're trying something new. You're learning. You're adapting. You're growing. This rich information stream gives you feedback, comparison points, and context. And that’s what gets you to real quality.
Quality isn’t how long you spent or how hard you tried. It’s how accurately you met the defined quality target.
And that definition? It needs to come first. Before you start. Because if you don’t know what quality looks like, how will you ever reach it?
If your goal is to deliver a decent product, aim for decency first. That becomes your definition of quality. Trying harder isn't the answer if your approach doesn't achieve decency. Instead, try something different. Seek feedback. Iterate. Evolve.
Let’s be honest: most of us have jumped into building something without nailing down the requirements. I’ve even done it myself many times over the last two decades.
👉 And every single time I did, it came back to bite.
Projects launched without clear definitions of success often spiral out of control. The result reflects the chaos and assumptions surrounding it—not a strategic goal execution. And the consequences? Unhappy clients, unmaintainable codebases, wasted budgets, and indefinite deadlines.
Requirements First, Always
Every time a project I worked on turned into a mess, there was one common denominator: no one had taken the time to define the requirements and quality before starting. And yes, it’s tempting to say "we'll figure it out as we go," but let me be clear: that’s a trap.
Defining requirements isn’t bureaucracy. It’s clarity. It’s alignment. And it's what allows your team to make the dozens of small daily decisions that will either bring your product closer to success or veer it off into the unknown.
What Quality Really Means
Quality isn’t perfection. And it definitely isn’t some infinite ideal that your team has to chase until burnout.
Quality is the agreement on what "good" looks like for this specific product for these specific stakeholders at this specific time. It's contextual. It's practical. It's measurable.
✅ Hitting the defined requirements means you've hit the quality target. That is perfection—because it's exactly what it was supposed to be.
The Danger of Undefined Quality
Failing to define quality from the beginning puts it in the hands of chance, an unreliable planner.
What usually happens is that everyone on the team interprets quality differently. Engineers may overengineer. Designers may polish endlessly, and stakeholders might assume that "better" is always possible. Expectations rise, communication breaks down, and nobody ends up happy.
Under- and Overengineering: Two Sides of the Same Coin
Overengineering involves investing excessive time and resources into unnecessary features or architecture, while underengineering entails skimping on essential standards and failing to fulfill basic expectations.
Both are failures. Both come from not having a clear definition of what was actually needed.
Who Defines Quality?
You do. Or, at least, you should.
The CTO, the product owner, and the lead engineer—someone who has to take the initiative to define success and communicate it clearly to the team.
But don’t do it in isolation. Talk to your stakeholders, clients, users, and investors. Your definition of quality may differ greatly from theirs, and without alignment, you’re guaranteed to miss the mark.
🎓 Requirements, Qualities, and Context in Software Development
In the dynamic world of software development, the decision-making process is often complex and multifaceted. Today, I want to delve into three critical aspects of this process: requirements, qualities, and, most crucially, the context. These elements are the bedrock of successful software development, yet their interplay is often misunderstood or overlooked.
Be Honest About What You Can Deliver
Quality isn't a wishlist for the perfect product. It’s the realistic expectation for what can be achieved within given constraints.
Think of it as a Christmas wishlist where you already know the budget. You can want everything, but you better prioritize what matters. You can always add more later, but making promises you can’t deliver only guarantees disappointment.
Set the Bar Where It Belongs
It’s better to revise quality expectations and iterate than to promise the moon and miss. Your reputation, team morale, and users’ trust are all on the line.
Yes, perfection is possible—but only when you define it correctly. Not as some abstract, impossible-to-reach goal, but as a concrete, shared understanding of what success means.
Continue Reading & Listing About Quality in Devlopment
https://www.researchgate.net/publication/279177815_Quantity_yields_quality_when_it_comes_to_creativity_a_brain_and_behavioral_test_of_the_equal-odds_rule
https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2019.00355/full
Share this post