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 Sunk Cost Fallacy in Software Projects: When to Walk Away

The “sunk cost fallacy” is a classic trap that leads organizations to keep investing in projects that are already over budget and behind schedule. In software development, this fallacy can be especially damaging, as costs spiral, returns are uncertain, and the final product has limited resale or tangible value. Yet many teams persist, driven by the belief that they’ve already invested too much to abandon the project now.

The sunk cost fallacy in software projects often leads teams to continue investing in failing initiatives, even when the chances of success are low.

This mindset can cause companies to continue investing in projects with diminishing chances of success.

Why Software Projects Are Uniquely Prone to the Sunk Cost Fallacy

Software projects are complex, hard to estimate, and, unlike physical assets, don’t result in a tangible product. This makes them highly susceptible to the sunk cost fallacy.

Why Software Has No Tangible Fallback Value

• Software lacks the material value of a physical asset. For example, if you build a house and it goes over budget, you at least end up with a physical structure with market value. Software, however, is a set of digital instructions stored on servers. If a project fails, what remains is often worthless—it can’t be sold off or repurposed easily.
• This lack of residual value makes it hard to justify pouring more money into a failing project, yet many teams continue doing so to "complete" something, even if the return on investment is unclear.

Over-Optimistic Vendors and Scope Creep

• Software vendors can sometimes over-promise to win a contract, painting an overly optimistic picture of the product’s capabilities. When the time comes to deliver, they may struggle to meet the agreed specifications and timeline. In these cases, the vendor might request more money and time to compensate for unforeseen challenges or their own initial overestimation.
• With each delay and budget increase, the customer faces the difficult decision to keep funding the project or cut their losses. However, due to the sunk cost fallacy, decision-makers often feel pressured to stick with the vendor and project, fearing that backing out would mean wasting all previous investments.

Why Software Projects Are Hard to Estimate

• Estimating software projects is notoriously difficult. Requirements frequently change, new features are added, and unexpected complexities arise. Each adjustment drives up the cost, and each delay extends the timeline, yet the project remains incomplete and generates no revenue until launch.
• Scope creep, where the project grows beyond the original plan, is common in software. In the quest to make the investment worthwhile, teams often add more features, which only compounds costs and delays. Ironically, these “extra features” are frequently proposed by the very vendors who oversold the project in the first place, further ensnaring clients in the sunk cost trap.

Labour Costs and Team Scaling Challenges

• Software development demands highly skilled and highly paid developers, project managers, and testers. When projects fall behind, organizations face the choice of either adding more resources (which drives up costs further) or extending deadlines (which impacts business timelines).
• However, adding more developers doesn’t always work. Additional team members require communication and oversight, which can actually slow down progress. As teams continue spending, the sunk cost fallacy may convince them to keep funding the project, even if a fresh assessment suggests it may not succeed.

Why Failed Software Has Little Residual Value

• Failed software projects offer almost no residual value. In construction, a half-finished building or the land itself still holds some market worth, while a car with issues can be sold for parts. But if you cancel a software project that isn’t functional, all you’re left with is code that may never be used.
• This lack of tangible fallback value can make decision-makers reluctant to pull the plug. Instead, they throw more money into the project, hoping to “get something out of it,” even as the financial return diminishes.

Real-World Examples of the Sunk Cost Fallacy

Here are a few common scenarios where software projects fall prey to the sunk cost fallacy:

Government Software Initiatives:

Government software projects are highly visible and politically sensitive, often leading contractors to overstate what they can deliver to win bids. As costs escalate, governments continue funding these projects rather than cancelling them, fearing backlash over wasted taxpayer money.

Corporate Legacy Systems: 

Corporations sometimes rely on outdated software that becomes buggy and hard to maintain. Rather than shifting to modern alternatives, they continue funding updates to these legacy systems to avoid the costs of migrating to new platforms, even though this ongoing investment may ultimately be wasteful.

Healthcare Management Systems:

Healthcare software often requires customization to meet complex regulatory needs. As these projects run over budget, providers may feel trapped, continuing to fund projects that are far more expensive than anticipated because switching systems mid-stream would appear even costlier.

How to Avoid the Sunk Cost Fallacy in Software Projects

Here are some strategies to help identify and avoid the sunk cost fallacy in software projects:

Conduct Regular Project Evaluations:

Schedule periodic evaluations to assess whether the project remains viable. If costs have consistently outpaced projections, reassess whether the end product will still provide the intended benefits. At each major milestone, be prepared to make a tough call if necessary.

Focus on Minimum Viable Product (MVP):

Rather than trying to include every feature originally promised by the vendor, focus on creating an MVP that fulfils the most essential functions. This approach can deliver value faster and help reveal whether the project is worth further investment.

Prioritize Strategic Value, Not Sunk Costs:

Base decisions on future potential, not past expenses. If an objective assessment doesn’t justify further spending, it may be time to pull the plug. Pouring money into a project purely to avoid “wasting” what’s already been spent only leads to further losses.

Establish Accountability for Vendors:

Hold vendors accountable for delivering on their promises. Rather than paying more to accommodate their mistakes or misrepresentations, ensure that contracts include penalties for underperformance or delivery delays. This can help reduce vendor-driven costs that contribute to the sunk cost trap.

Build Awareness of the Sunk Cost Fallacy:

Make sure everyone involved in the project—from stakeholders to project managers—understands the sunk cost fallacy and its dangers. With awareness, teams are better equipped to make objective decisions and focus on the project’s long-term value.

Conclusion

Software projects are particularly vulnerable to the sunk cost fallacy due to their intangible nature, high labour costs, and vendors who may oversell their solutions. Recognizing this risk can help teams avoid the trap of “just a little more” spending when the potential for return is low. In the end, software development should always be guided by future value rather than past expenses. Cutting losses early on may be the smartest move, allowing organizations to allocate resources to projects with clearer paths to success.

If you’re involved in a project that keeps demanding more time and money but still isn’t delivering, it might not be a technical problem.

I help people step back, assess what’s really going on, and make practical decisions about how to move forward.

If something feels like it’s going in the wrong direction, take a look at my TechFix service.

From Agile Dreams to Crunch Reality in Software Projects

In the ideal world of software development, projects begin with high hopes and well-intentioned plans. Agile methodologies, with their emphasis on flexibility, iterative progress, and team collaboration, promise a structured yet adaptable approach to bringing a product from concept to completion. However, as many developers know all too well, tthe shift from Agile to crunch can be surprisingly fast—and difficult to reverse, driven by the harsh realities of limited budgets, extensive scopes, and minimal staffing. Let's explore how this transformation occurs and what it means for developers on the ground.

Agile methodologies are designed to improve flexibility and delivery, but in real-world software projects they often break down under pressure, leading to crunch and burnout.

The Promise of Agile

Agile development offers a framework that allows teams to respond to change quickly and efficiently. The core principles of Agile—such as regular feedback loops, continuous improvement, and close collaboration—are designed to enhance productivity and ensure that the project stays aligned with the client’s evolving needs.

Core Agile Practices in Software Development

• Sprint Planning: Setting realistic goals for short, manageable periods (typically two weeks).
• Daily Stand-ups: Keeping the team synchronized and addressing any blockers promptly.
• Iterative Development: Delivering incremental improvements and new features regularly.
• Retrospectives: Reflecting on what went well and what could be improved after each sprint.

These practices aim to create a sustainable and productive development environment. However, the shift from Agile to Crunch often begins when the real-world constraints start to outweigh these principles.

Why Agile Projects Drift into Crunch

Here are the most common reasons Agile projects drift into crunch:

1. Limited Budget: Financial constraints can limit resources, forcing the team to do more with less. This often means longer hours and increased pressure to deliver the same quality of work within a shorter time frame.
2. Expanding Scope: Also known as scope creep, this occurs when new features and requirements are added continuously, often without adjusting the project timeline or budget. The result is a bloated workload that far exceeds initial expectations.
3. Minimal Staffing: A small team might be manageable at the project’s start, but as the workload grows, the lack of additional hands can lead to burnout and extended work hours to meet deadlines.

How Agile Projects Turn into Crunch

Imagine a small development team starting a project with a clear set of goals and a realistic timeline. The project begins with Agile practices, and the first few sprints go smoothly. However, halfway through the project, the client requests several new features, significantly expanding the project’s scope.

At the same time, budget constraints prevent the hiring of additional developers. The project manager, under pressure to meet the original deadline, decides to extend work hours and compress sprint cycles to accommodate the new requirements. What started as a well-paced Agile project quickly turns into a crunch situation, with developers working nights and weekends to stay on track.

How to Manage Agile Without Falling into Crunch

While crunch can sometimes feel inevitable, there are strategies to manage and mitigate its impact:

• Realistic Planning: Set achievable goals and be transparent about the limitations of time and budget from the outset. Make it clear to stakeholders that adding features will require adjustments to the timeline or additional resources.
• Prioritization: Use Agile’s iterative nature to prioritize features and tasks. Focus on delivering the most critical aspects of the project first, ensuring that the essential parts are completed on time.
• Communication: Maintain open lines of communication with the team and stakeholders. Regular updates on progress and challenges can help manage expectations and avoid last-minute surprises.
• Flexibility: Be prepared to adjust the project scope or timeline as necessary. Agile is about being adaptable; use this flexibility to find a balance that minimizes the need for extended crunch periods.

Conclusion

Transitioning from Agile to Crunch is a common challenge in software development, often driven by the realities of budget constraints, expanding scopes, and limited staffing. While crunch can sometimes be unavoidable, understanding the factors that lead to it and implementing strategies to manage it can help maintain a healthier and more productive development environment.

As developers, it’s crucial to advocate for realistic planning and sustainable practices, ensuring that the Agile principles we start with are not lost in the face of real-world pressures. By doing so, we can strive to create a work environment that values both productivity and well-being.

If your project started with a clear plan but now feels rushed, pressured, or out of control, you’re not alone.

I help teams step back, simplify what’s going on, and get projects back to something sustainable and workable.

If things feel like they’re slipping into crunch, take a look at my TechFix service.