Skip to content

Bug or change request: why the distinction helps

The question sounds like laying blame and is really a question about expectation: should it have been different, or should it become different? The answer determines urgency, order and cost.

  • AudienceClients, project managers
  • LevelCollaboration
  • Reading timeabout 6 minutes
  • Last updated16 October 2026

What you will learn

  • What distinguishes the two — in one sentence
  • Why the classification is useful for both sides
  • How to handle the frequent in-between case
  • What belongs in a useful report

The difference in one sentence

A bug is a deviation from what was agreed or from what can usually be expected of software of this kind, such as crashes, data loss or security vulnerabilities. A change request is a deviation from what you wish for today. Both are legitimate; only the handling differs.

  • Bug: The list shows cancelled orders as open, although it was agreed that cancelled does not mean open.
  • Change request: The list should additionally be filterable by processor. This was never agreed, but makes sense.
  • Cannot be decided: The list shows orders without line items. Nothing was ever said about this.

Why the classification helps both sides

For you: A bug is fixed with priority and, within the warranty period or under a maintenance contract, is generally not charged separately; the exact terms are set out in the contract. A change request is scheduled, estimated and decided on deliberately — you determine whether it takes priority over other work.

For us: Bugs are a quality signal. If several occur repeatedly in one area, we look at that area instead of fixing the symptoms one by one. If the two are mixed, this signal is lost — and a long list then says nothing about how the application is doing.

An example from practice

The frequent in-between case

The third case above is everyday reality: nothing was ever agreed, and now it turns out that the software behaves differently from what was expected in one situation. Neither a bug nor a wish, but a gap in the original description.

We handle it like this: the gap is named, the desired rule is defined, and the implementation is scheduled like a change — without a discussion about who should have foreseen it. That dispute regularly costs more than the implementation.

If the gap acutely affects someone, it is moved forward. The classification determines the order, not the urgency.

What belongs in a useful report

  • What you did — the steps, not the summary.
  • What you expected.
  • What happened instead, as literally as possible.
  • When it happened and under which user. This narrows the search in the log.
  • Whether it is repeatable or occurred only once.

“Saving doesn't work” costs two follow-up questions. “Yesterday around 2 pm, as Ms Meier, I saved an order with three line items; I expected the overview, I got an empty page — it worked on the second attempt” is a troubleshooting job that starts the same day.

Common misconceptions

Only if that was what was agreed. The software cannot know what was never discussed — which is why the third case above is so common.

It means you decide. Some requests can be included almost for free in a change that is due anyway — we will tell you so.

It is made jointly, because it depends on the agreement. Where nothing was agreed, there is no one-sided answer.

Read next

From idea to tasksHow agreements come about that you can refer back to later.
Why software tests need concrete failure casesHow a fixed bug stays fixed.
Git and version controlWhere you can look up what was decided and when.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design, and writes here about decisions that arise in real projects.

Questions about this article? Write to us