Client vs Supplier: What Counts as a Bug?
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.
This disagreement often shows up in simple, real-world scenarios. 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.
Implicit vs Explicit Requirements in Software Projects
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 Blurred 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 Resolving Bug Disputes
So, how do we navigate these challenges and hold suppliers accountable? Here are some guiding principles:
Clients Shouldn't Have to Spell Out the Obvious: Suppliers should apply industry best practices and anticipate common-sense expectations.
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.
Minor Fixes Should Be Resolved, Not Argued Over: Simple fixes, like adding basic validation, should not become lengthy discussions about scope.
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.
If something clearly isn’t working but turns into a debate instead of getting fixed, you’re not alone.
I help people cut through unclear requirements and focus on getting systems working properly.
If issues feel harder to resolve than they should be, take a look at my TechFix service.