When Is a Bug Really a Bug? (And When It’s Not)

In many software projects, the line between a bug and a change request is often unclear—and this ambiguity can lead to delays, disputes, and increased costs.

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?

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:

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.

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.

The Purpose and Pitfalls of Bug Triage in Agile Projects

Bug triage in Agile is meant to prioritise and resolve defects quickly, but when misused it can slow delivery, create conflict, and reduce overall software quality.

Bug triage is crucial in ensuring quality and delivering value in any software delivery project, especially those adopting Agile methodologies. 

The purpose of bug triage is simple yet critical: to assess, prioritize, and plan the resolution of defects in a way that aligns with the project’s goals and timelines. However, when poorly executed, bug triage can drift away from its intended purpose and hinder progress, ultimately threatening the project's success.

This post explores the purpose of bug triage, common pitfalls that arise, and how teams can steer this essential process back to the principles of Agile.

The Purpose of Bug Triage in Agile

In Agile, bug triage is more than just a meeting to discuss defects. Its purpose is to:

1. Evaluate Defects: Determine the validity and severity of reported bugs.

2. Prioritize Issues: Assign urgency based on the impact on functionality, user experience, and business objectives.

3. Facilitate Collaboration: Foster open communication between developers, testers, and stakeholders to address issues efficiently.

4. Enable Quick Feedback Loops: Stay true to Agile principles by resolving defects swiftly and incorporating fixes into the delivery cycle.

At its best, bug triage aligns the team on priorities, empowers quick decision-making, and maintains a clear path toward delivering high-quality software.

When Bug Triage Starts to Fail

Despite its noble intentions, bug triage can quickly derail, leading to frustration, inefficiency, and a departure from Agile principles. Here are some of the common signs and issues:

1. Excessive Pushback on Bugs

Stakeholders may question the validity of defects, claiming that they:

• Bugs are not part of the original requirements.

• Are not reproducible, even when intermittently observed.

• Should be closed despite unresolved issues, often to reduce visibility or perceived system instability.

Such behaviours create an environment where legitimate defects go unaddressed, leaving the system vulnerable.

2. Implicit Requirements Ignored

Software often carries implicit expectations—functionality that users naturally assume will work without needing explicit documentation. Dismissing these as “not requirements” undermines the user experience and trust in the system.

3. Pressure to Reclassify Bugs

There is often pressure to:

• Downgrade the severity of critical defects.

• Convert bugs into change requests, shifting the burden of resolution away from the immediate sprint or release.

These tactics erode the team’s credibility and disrupt Agile’s focus on delivering working software incrementally.

4. Lengthy Discussions on Simple Fixes

Some bugs, which could be resolved in minutes, instead go through protracted debates to gain acceptance. This delay fixes and clogs the pipeline, frustrating developers and testers alike.

5. Visibility and Credibility Issues

Attempts to reduce the visibility of unresolved bugs—by closing them prematurely or misclassifying their impact—mask deeper systemic issues. This can result in a false sense of readiness, jeopardizing the project’s go-live success.

How to Fix Bug Triage in Agile Teams

To restore the purpose of bug triage and ensure it supports Agile delivery, consider the following strategies:

1. Focus on Collaboration, Not Conflict

Bug triage should be a forum for collaboration rather than contention. Establish a culture of openness where all stakeholders recognize the shared goal of delivering quality software. Encourage constructive dialogue over blame or defensiveness.

2. Define Clear Criteria for Bugs

Set clear guidelines for:

• What constitutes a valid bug.

• How severity and priority are assigned.

• How to handle intermittent issues and implicit requirements.

Having agreed-upon standards reduces subjectivity and expedites decisions.

3. Empower the Team to Act

Agile thrives on the ability to make quick adjustments. For straightforward bugs, allow developers and testers the autonomy to resolve and validate fixes without prolonged debate. Reserve triage discussions for complex or high-impact issues.

4. Respect the User’s Perspective

Implicit requirements reflect the end-user’s expectations. Dismissing these can erode trust and usability. Ensure that user experience is a core consideration during triage.

5. Track Decisions Transparently

Documenting the rationale for closing, downgrading, or converting bugs ensures accountability and visibility. This practice builds trust among team members and stakeholders.

6. Align with Agile Values

Remember the Agile manifesto: “Individuals and interactions over processes and tools” and “Responding to change over following a plan.” Let these principles guide your approach to bug triage, focusing on value delivery and adaptability.

Conclusion

Bug triage is a vital component of Agile delivery, but it requires diligence and alignment with core principles to be effective. By fostering collaboration, establishing clear criteria, and focusing on delivering value, teams can transform triage meetings from a source of frustration into a cornerstone of success.

If your team is struggling with bug triage, reflect on the issues outlined here. Small adjustments can make a significant difference, steering the process back to its intended purpose and ensuring your project remains on track.

If bug triage feels more like a blocker than a solution, you’re not alone.

I help teams simplify processes and remove friction so issues get resolved quickly.

If delivery feels slower than it should be, take a look at my TechFix service.

From Office Desks to Bar Stools: How Computing Changed How We Work

Sitting here in this lively bar, I’ve got my laptop in front of me, a beer to my right, and a cosy buzz of conversation and music in the air. It’s one of my favourite ways to spend an afternoon—writing, reflecting, and soaking up the human energy around me. There’s something wonderful about being surrounded by people, watching the neon lights glow and dance off the bar's bottles, all while tapping away on my keyboard.

The way we use computers has changed dramatically—from fixed office setups to fully mobile, connected devices that allow us to work from anywhere.

How Computing Used to Work

It’s hard not to step back and appreciate how far we’ve come. When I started working with computers, they were anchored to office desks—big, boxy towers paired with CRT monitors, a wired keyboard, and a clunky mouse. There was no internet, no sense of mobility. That machine, likely a 286, was plugged firmly into a 13-amp socket, designed solely for crunching numbers on spreadsheets or typing up documents.

Working Anywhere: The Modern Reality

Now, here I am. My keyboard and screen are combined into one sleek device that runs on battery power for hours. I’m connected to the world through a hotspot on my phone, and I can work from literally anywhere—be it an office, a coffee shop, or, in this case, a festive bar on a Friday afternoon.

Technology and Human Connection

As Christmas draws near, the bar is filling up. People are getting ready for their holiday nights out, their laughter and excitement building as the evening progresses. Every person here is carrying a tiny, powerful computer in their pocket—a smartphone with a camera that captures the memories of the night in vivid, sharable detail. In real-time, these moments are sent off into the ether, to social media platforms or private group chats. A snippet of their night, immortalized in a digital file.

It’s astonishing to think about. Not long ago, documenting a night like this might have required a bulky camcorder or a dedicated camera. Now, it’s as simple as a tap on a screen. And for many, this seamless recording and sharing of life feels utterly normal—so normal that it barely registers as remarkable.

But I can’t help pausing to appreciate the bigger picture. I think about the transformation of human connection—how far we’ve come from those static office computers. The tools we use to connect and communicate have evolved beyond what we could have imagined. Even if you’re not out tonight, you’re likely at home streaming music or watching a movie on your smart TV—another testament to how deeply digital technology has woven itself into our lives.

And here I am, sitting in a bar, enjoying this moment of quiet reflection amidst the buzz, writing about it all. This, too, will become a digital artefact—a blog post shared with the world, contributing to the endless stream of content that connects us.

So as the night unfolds and this place gets busier, I’ll raise my glass to how far we’ve come and to the exciting ways we continue to connect and share our stories.

Cheers to technology, humanity, and the holiday season ahead.

If work is starting to feel overwhelming or harder to switch off from, you’re not alone.

I spend a lot of time helping simplify systems and reduce unnecessary complexity.

You can take a look at my TechFix service if that sounds familiar.

Over-Promise and Under-Deliver: Why Projects Fail

In the competitive world of technology and software, promises are currency. Companies promise innovation, efficiency, and transformation to secure deals. But what happens when those promises exceed what can be delivered? "Over-promise and under-deliver" is not just a cliché; it’s a costly pitfall that affects everyone involved in a project.

Over-promising in software projects often leads to missed deadlines, increased costs, and failed delivery—especially when expectations are not aligned with reality.

Let’s explore the repercussions of over-promising, how to identify it early, and what you can do if you find yourself in such a situation.

The Problem with Over-Promising

To win projects, suppliers often overstate the capabilities of their solutions. They may promise features or timelines that their product cannot realistically deliver. This overconfidence can stem from various factors:

• Lack of Suitable Products: The solution isn’t fit for purpose and requires significant modification.
• Underestimating Costs or Timelines: Sales teams downplay the complexity of the project.
• Knowledge Gaps: The supplier doesn't fully understand the client’s requirements or their own product’s limitations.

For the client, the gap between expectations and reality can lead to frustration, wasted time, and wasted resources. For the supplier, the cost is stressed teams and tarnished reputations.

Here are some of the most common impacts:

The Impact on Clients

Clients pay the highest price when promises fail to materialize. Here’s how:

1. Wasted Resources: Clients often deploy additional staff to compensate for shortfalls, increasing costs. These resources are diverted from other projects or responsibilities.
2. Frustrated Teams: The client’s employees, often the first to notice issues, scramble to fill gaps, resulting in stress and burnout.
3. Diminished Trust: Stakeholders lose faith in both the project and the supplier, damaging relationships and future collaborations.

The Impact on Suppliers

Suppliers also bear the burden of over-promising:

1. Disjointed Handoffs: Sales teams, who made the lofty promises, often move on to new deals, leaving delivery teams to face the fallout.
2. Pressure on Delivery Teams: Developers and implementers work under intense stress, trying to retrofit unsuitable products to meet commitments.
3. Reputational Damage: Failing to deliver tarnishes the supplier’s credibility, affecting future sales and partnerships.

Early Warning Signs of Project Failure

Spotting over-promising early can save a project from disaster. Look for these red flags:

• Missed Deliverables: Early milestones are delayed or skipped entirely.
• Shifting Blame: Teams start pointing fingers, and excuses become frequent.
• Compounded Delays: One delay leads to another, creating a domino effect.
• Rumours and Discontent: On-the-ground staff discuss missing features or limitations compared to the promised solution.
• Gaps in Requirements: Functionalities of the old system are not replicated in the new solution.

What to Do When a Project Starts to Fail

If a project veers off track, several options are available. None are ideal, but understanding the trade-offs can help you choose the least damaging path:

1. Pull the Plug: If the project is beyond salvageable, cutting your losses may be the wisest choice.
2. Accept a Reduced Scope: Scale back expectations to align with what the supplier can realistically deliver.
3. Learn and Move On: Document lessons learned and apply them to future projects.
4. Refocus on Minimum Viable Functionality: Strip the project to its core essentials, ensuring at least some value is delivered.
5. Deprioritize: Shift focus to other initiatives, letting this project take a backseat while still attempting to salvage some outcomes.

How to Prevent Over-Promising in Projects

The best way to avoid these challenges is through thorough preparation and due diligence:

• Validate Supplier Claims: Insist on real-world examples and case studies that demonstrate the supplier’s ability to deliver similar solutions.
• Engage Your Team: Involve your staff early to assess proposals and match them against actual needs.
• Define Requirements Clearly: Document precise requirements and ensure the supplier can meet them.
• Set Gates and Checkpoints: Break the project into phases with clear milestones and validation steps.
• Prioritize Transparency: Establish an open dialogue with suppliers to ensure alignment and realistic expectations.

Conclusion

Over-promising and under-delivering isn’t just a project management issue; it’s a systemic problem that creates stress, wastes resources, and undermines trust. By recognizing the warning signs and taking proactive steps, organizations can protect themselves from falling into this trap.

The key takeaway? Due diligence is your best defence. Understand what you’re buying, involve your team, and ensure the supplier can deliver what they promise. In the end, realistic expectations lead to successful partnerships—and projects that deliver real value.

If your project doesn’t match what was originally promised, you’re not alone.

I help people cut through unrealistic expectations and get things back on track.

If things feel like they’re drifting away from the original plan, take a look at my TechFix service.