Wednesday, January 22, 2025

When Is a Bug Really a Bug?

A colorful and humorous illustration of a giant cartoon insect sitting on a laptop screen, symbolizing a software bug. A frustrated client points at the bug, while a confused supplier shrugs dismissively. The office setting includes error messages on the screen and scattered documents, highlighting the challenges of software development.
In software development, few topics create as much debate as defining a "bug." From a client's perspective, a bug is anything that doesn't work as expected. 

From a supplier's perspective, however, a bug is often dismissed as a missing requirement, conveniently reframed as a change request to avoid responsibility. This discrepancy leads to frustration, delays, and a growing sense of mistrust between the two parties. 

So, where do we draw the line?

The Client vs. Supplier Perspective

Clients rely on software to function intuitively and predictably. When something disrupts their workflow or doesn't meet reasonable expectations, they rightly label it as a bug. Conversely, suppliers frequently hide behind vague requirements, using loopholes to avoid fixing issues unless explicitly documented.

For example, consider an online form designed to collect UK phone numbers. Is that a bug if a user can enter letters instead of numbers? The client would argue yes—it prevents valid data entry and should have been accounted for. The supplier, in contrast, might claim that since validation rules were not explicitly stated, they are not responsible. This kind of evasiveness only serves to frustrate clients and degrade trust in the development process.

The Implicit vs. Explicit Requirement Debate

Software inherently includes implicit requirements. Much like a cookbook doesn’t instruct the reader to fetch a pan before cooking, some aspects of functionality should be assumed. However, suppliers often exploit ambiguity to deflect responsibility, insisting that anything not meticulously spelt out is outside the scope.

Taking this a step further, consider high-level system-wide requirements, such as accessibility compliance. If a client states that a website must adhere to Web Content Accessibility Guidelines (WCAG), does this mean they need to specify every single place it applies? No reasonable supplier should need such micromanagement. Yet, when accessibility issues arise, suppliers often attempt to classify them as change requests rather than take accountability for meeting industry standards.

The Risk of Cloudy Boundaries

When suppliers dodge responsibility by blurring the distinction between a bug and a change request, projects slow down, costs rise, and clients are left with a system that doesn't meet their needs. This kind of behaviour not only undermines collaboration but also erodes confidence in the supplier’s ability to deliver a quality product. Clients expect professionalism, not excuses.

A Practical Approach to Resolution

So, how do we navigate these challenges and hold suppliers accountable? Here are some guiding principles:

  1. Clients Shouldn't Have to Spell Out the Obvious: Suppliers should apply industry best practices and anticipate common-sense expectations.

  2. Refusing to Fix Clear Issues Is Bad Faith: If a reasonable user would expect certain functionality to work in a certain way, the supplier should address it without excessive debate.

  3. Minor Fixes Should Be Resolved, Not Argued Over: Simple fixes, like adding basic validation, should not become lengthy discussions about scope.

  4. Transparency and Accountability Matter: Suppliers should not weaponize requirements documentation to avoid doing the right thing.

Conclusion

The line between a bug and a change request isn’t always clear, but clients shouldn’t have to fight tooth and nail to get a functional product. Suppliers who play games with definitions to dodge responsibility only harm their own credibility. Instead of hiding behind technicalities, suppliers should prioritize collaboration, efficiency, and above all, delivering software that works as expected.