Bugs: The Developer, an All-Too-Easy Scapegoat

A bug in production. Whose fault is it?

Bugs: A Development Issue?

There is, of course, the issue of skill. Our industry is so short on workers that it’s easy to break into it with almost no knowledge of the field. Too many bootcamps promising the moon, too many schools that only teach the latest technologies, and very few organizations that actually teach the art of development (let me be clear: I’ve met some amazing developers who came out of bootcamps, but I’m saying that these people were amazing in their own right, and the bootcamp had nothing to do with it). As a result, we’re training people to create technical debt.

However, well-established practices exist that can reduce the occurrence of bugs: static typing (with all due respect to JavaScript enthusiasts), simple and advanced testing practices (including Test-Driven Development), not to mention functional programming (long live pure functions), and, well before all that, work on modularity, the significance of which is often underestimated.

But to be honest, if I’m bringing up the subject of competence, it’s to get it out of the way as quickly as possible, because the question “whose fault is it?” is a very bad question. Pointing fingers isn’t enough; we need to fix things, we need to help, and before that, we need to recognize that the problem is, as is often the case, systemic in nature.

What About Functional Design?

To focus solely on developers’ skills is to ignore an essential dimension of the problem: functional design. For while some bugs result from development that doesn’t conform to the specification, an even larger portion stems from poorly designed software. Edge cases, in particular, are frequently overlooked, but often it is the design as a whole that turns out to be flawed. The Larousse dictionary, in fact, defines a bug as “a defect in the design or implementation of a computer program, which manifests itself as anomalies in the computer’s operation.”

Having cut my teeth in the glory days of waterfall methodologies, when software development was governed by thick specification documents, I’ve heard this phrase far too often: “This may not be what you wanted, but it’s what was specified.” The user, for their part, couldn’t care less whether the bug is a design flaw or an implementation error. You’ve never heard a user say, “Nothing works, but since the development conforms to the specification, that’s fine with me.” As for me, I’ve heard far cruder things, which decency and my mother forbid me from repeating here…

Functional analysis and design, like everything else, can be learned and honed. Here, too, there are well-established practices, foremost among which is Example Mapping. This knowledge is all the more valuable because the later a bug is detected, the more expensive it is to fix. Ideally, the bug will be detected before a single line of code has been written, and we’ll refer to it as a “design flaw.”

On closer inspection, the distinction between functional design and development (to put it bluntly: thought vs. action) may be a problem in and of itself. So it’s the organization itself that needs examining.

Organizational causes

As is often the case, the root causes are organizational, and that’s a tragedy, because poor organization will always trump even the best intentions.

Here are a few ideas:

Deadline pressure: management demanding the impossible, deadlines that are impossible to meet without incurring massive technical debt, a classic scenario. In the worst-case scenario, it’s the PoC that gets deployed to production because no one knows how to tell the difference…
Staff turnover: “team turnover” means “loss of knowledge.” A developer soon finds themselves maintaining a system they don’t understand, for a business domain they don’t understand. We must therefore ask why the organization fails to stabilize its teams.
Then there’s the very definition of teams. As we know (Conway’s Law), software architecture reflects the organization’s communication structures. If you haven’t properly considered modularity at the level of your IT systems, there’s a good chance you’ve formed teams that run counter to the natural boundaries of your domain and created an endless source of bugs.
And indeed, the road to hell is paved with good intentions: even setting up a quality assurance team can backfire and become an incentive to create bugs. This paradox stems from the fact that we cannot separate “doing” from “doing better.”
Ultimately, it’s a matter of corporate culture and ambition: tolerating bugs is already encouraging them. Conversely, a Zero-Bug policy, which prioritizes fixing bugs over any new development, sends a strong signal that everyone picks up on, from the developer to the user, because even a minor bug devalues the application and erodes the trust the user had placed in it. An inconsistent result in a minor case is enough to sow doubt: “What if other results were wrong without me realizing it?”

It’s easy to blame developers. Building an organization that doesn’t produce bugs is much harder: that’s precisely why it’s a management issue, not just a development one.