In this post, I would like to share my reflections about what software without bugs actually means, and my own tentative answer to this question. As someone who is currently at the early stage of his career, I find myself constantly overwhelmed by questions about the world that surrounds us.
Little do people realize how challenging it is sometimes to find a truth among the tremendous amount of personal matters and contradictory information that floods the software industry. You open one book, and it tells you to structure your code one way; you open a blog post by a respected authority, and they claim the exact opposite is the only path to salvation. Your own point of view may fluctuate from one respected authority to another, driven not by deep understanding, but by experience deprivation and an immaturity at a certain degree.
I wish I had the answer to this, at first glance, simple question: How do we craft software without bugs? But the more I learn, the more I realize the question is not simple at all. In this article, I will try to share my reasoning path while striving to address this question, not as an expert teaching a lesson, but as a learner trying to organize the chaos.
Defining the Phenomena
First of all, let's define what software exactly is. What are the properties of this phenomena? We can look at various definitions, including those from Wikipedia, which speak of instructions and data. But to me, they miss the human element.
I believe software may be described with the following definition: it is an outcome expressed in numerical implementation from one or a group of individuals' cognitive efforts.
The main parts here are "numerical implementation" and "one or group of individuals." Thus, these are the part and parcel of every piece of software. It is impossible to separate the code from the people who thought it up. And now, let's consider each part's contribution through the "bug prisma."
It is easy to figure out what "numerical implementation" stands for. Apparently, this is the actual unit that contains the namely "bug" - the syntax error, the null pointer exception, the memory leak. Only there can people visibly see the outcome of cognitive efforts. However, currently, we are only on the top of the iceberg. If we stay here, we only see the symptoms. It is way more fascinating to observe the root causes, which lie beneath the surface in the minds of the creators.
The Subjectivity Trap
Namely, we must look at the individuals whose ideas were described through the code. This is where the true complexity arises.
Given that each human being has their own opinion, it is sometimes rather challenging to argue with an opponent regarding how software should be built. If you are discussing a mathematical algorithm, you both have a solid foundation which is actively used during arguments; math is objective. 2 + 2 will always equal 4.
Nevertheless, on no account should you forget about topics that don't have any objective bases under the hood. In software engineering, these topics are everywhere. There are various examples such as codestyle, architectural patterns, the choice of libraries, or how to name a variable. In those cases, the "right" answer implies a consensus that doesn't exist. It mainly depends on the ability of another part to convince their opponent.
Whether it is group hierarchy (where the senior engineer simply overrules the junior) or tricky language (using buzzwords to sound smarter), the decision is often social, not technical. Perhaps, from each such argument raises a potential bug. Who knows?
When a team cannot agree on a solid mental model, the code becomes a patchwork of conflicting ideas. One part of the system assumes X, while the other part assumes Y, because the two creators could not find a common truth. Therefore, whether ostensively or not, a group of people will inevitably encounter ambiguous topics where objective facts don't make a lot of sense. And in that ambiguity, the bugs hide.
The Solo Creator vs. The Vacuum
This line of reasoning leads me to a specific hypothesis: What if software was crafted by only one individual?
Will it mean that software will contain fewer bugs? Well, empirically speaking, many of the greatest pieces of software in history - the initial versions of Linux, languages like Python, or tools like Redis - were designed in solo or by a very small core, applying a decent amount of expertise of the creator.
Hence, we may say that there is less chance to encounter a bug if the software is audited by its creator alone. Why? Because a single individual does not need to argue with themselves. They do not need to convince an opponent or compromise on a vision. Their "cognitive effort" is unified. The mental model is consistent because it lives in one head. There is no loss of information in communication.
However, we must be realistic. In that case, it is rather challenging to produce a lot of software. One human being has limits.
Wait, but isn't it said that quality != quantity? Saying that, even a small chunk of code, written perfectly by one person, may commit to a massive impact. Perhaps we chase "scale" too much, and in doing so, we introduce the very bugs we try to avoid by adding more people to the team.
Only the solo creator may decide whether a decision matters or not. And it makes sense actually. They have the ultimate authority.
However, if you follow this path, you may end up in a vacuum where nobody can evaluate your ideas. You might build a perfectly consistent system that is completely useless, or you might miss a critical flaw because you have no "opponent" to test your logic against. The solo creator is a dictator, and while dictators are efficient, they are often wrong.
The Strong Leader: A Compromise?
Thus, does it mean that a small group of people will produce fewer bugs?
Perhaps the answer is not in "solo" vs "team," but in the structure of the team. Better to say: fewer people with a strong leader who can take responsibility for the decision.
If the main source of bugs is the ambiguity arising from endless arguments, then we need a mechanism to resolve those arguments definitively. We need a hierarchy that respects the "one mind" consistency of the solo developer, while utilizing the manpower of a team. We need someone to say, "This is the truth for our project," and end the debate before it turns into a bug.
Conclusion
Finally speaking, I wish I had a silver bullet and could easily respond to this question with a tutorial or a 5-step guide. But reality is more complex than a "Hello World" program.
This article is quite unfinished, much like my own understanding of this profession. I suspect that "software without bugs" is impossible as long as humans are the ones writing it, because humans are inherently full of contradictions. But perhaps, if we stop looking for technical fixes and start looking at how we communicate and organize our cognitive efforts, we might get closer to the truth.
Because I really don't know about the software yet. I am just trying to figure it out.