It's not a bug, it's a feature — meaning, origin, and differences

What “It’s not a bug, it’s a feature” means

“It’s not a bug, it’s a feature” — a phrase used by developers or managers to indicate that an unexpected program behavior is intentional, not erroneous. In the classic case, it’s a joke: everyone understands the behavior is wrong, but calling it a “feature” relieves tension. However, in real projects, the phrase is also used seriously — when the behavior actually matches the specification but does not meet user expectations.

The difference between a bug and a feature is often subjective. To a developer who wrote the code, a certain behavior might seem logical. To a user, it might seem unexpected and wrong. Subjectivity of perception is the main reason the phrase is so persistent. It shifts the conversation from “who is to blame” to “it was designed that way.” According to UX Collective, 40% of bugs reported by users are actually UX issues, not code errors.

In agile teams, the phrase is often used as a defense mechanism during demos. A developer demonstrates unexpected behavior, the product owner frowns, and the fateful phrase “it’s not a bug, it’s a feature” is uttered. Trust in the team determines whether the phrase is taken as a joke or an attempt to hide a problem. In a healthy team, such a joke defuses the situation; in a toxic one, it causes conflict.

History of the iconic phrase

The first known use of the phrase was recorded in 1976 in a DECUS (Digital Equipment Corporation User Society) bulletin. A user complained that the RUNOFF text processor incorrectly handled blank lines. The developer’s response: “It’s not a bug, it’s a feature — that’s how paragraphs are processed.” Since then, the phrase has become a symbol of defending code written “as is,” regardless of its actual quality.

The phrase gained popularity through the Jargon File — a dictionary of hacker slang that in the 1990s became the basis for the book “The New Hacker’s Dictionary.” In the Jargon File, the entry “feature” directly refers to bugs that became features because they were impossible or undesirable to fix. Example: the Caps Lock key on early terminals had no indicator light — this was a bug that became a feature “for blind typing.”

In the 2000s, the phrase moved into popular culture through internet memes. A picture of a cat captioned “It’s not a bug, it’s a feature” spread across forums and social media. In the gaming industry, the phrase is used especially often: glitches that don’t break gameplay are declared “features” for atmosphere. The cultural phenomenon has spread far beyond IT — the phrase can be heard in any context where an error is being excused.

The psychology of the excuse: why people say it

The psychological basis of the phrase is cognitive dissonance. A developer has spent hours writing code, and admitting the result is wrong means devaluing their work. The phrase “it’s not a bug, it’s a feature” reduces dissonance: the error turns into a deliberate decision, and the developer goes from being the culprit to being the author of the idea. It is a psychological defense mechanism that preserves self-esteem.

The second reason is fear of rework. Admitting a bug means going through code review, testing, and deployment all over again. A “feature” does not require fixing — the task is closed, the workload decreases. According to Microsoft Research, developers deliberately downplay the severity of bugs to avoid rework in 23% of cases. The phrase is a mild form of such downplaying.

The third reason is corporate culture. In some companies, bugs affect a developer’s KPIs, and finding a bug during code review is considered the author’s mistake. In such an environment, the phrase “it’s not a bug, it’s a feature” is a way to avoid negative career consequences. A healthy error culture (blameless culture) eliminates this reason: if bugs are not punished, they are easier to admit.

Where the line between a bug and a feature lies

A clear boundary exists only when there are Acceptance Criteria. If the behavior does not match any AC item — it’s a bug. If the behavior matches the AC but the user doesn’t like it — it’s a UX problem, not a bug. If there are no AC — any behavior can be declared a feature, and this is the main reason the phrase persists.

A practical rule: a bug is when a program does something it shouldn’t, or doesn’t do something it should, according to the specification. A feature is when a program does what was intended, even if the result surprises the user. Borderline cases: undefined behavior (the language doesn’t define the result), race conditions (manifest intermittently), edge cases (works for 99% of data).

For clarity, use a decision matrix:

• Behavior is described in the specification and implemented correctly — feature, even if you don’t like it
• Behavior is described but implemented incorrectly — bug, needs fixing
• Behavior is not described but logically follows from the requirements — undocumented feature, needs to be added to the specification
• Behavior is not described and is illogical — bug, requirements need clarification

The most dangerous case is when there is no specification, and the developer decides on their own what is a feature. In such projects, any error can be declared a “feature,” making the code unpredictable for the entire team. Clear Acceptance Criteria for every task — the only way to draw the line objectively.

Why confusing the two is dangerous for a team

The first danger is quality erosion. If every bug can be declared a feature, the team has no incentive to write quality code. Errors stop being fixed, technical debt grows, and users get used to “strange behavior.” Sooner or later, a competitor releases a product that works predictably, and users leave.

The second danger is team conflict. A QA engineer finds a bug, a developer says “it’s a feature.” Without objective criteria (Acceptance Criteria), the argument becomes personal: “you’re bad at testing” vs “you’re bad at programming.” According to PractiTest State of Testing 2023, “bug vs feature” disputes are one of the top three causes of friction between QA and developers.

The third danger is legal risks. In regulated industries (medicine, finance, aviation), the concepts of “bug” and “feature” carry legal weight. If behavior in medical software is declared a feature but leads to an incorrect dosage calculation — that’s not a joke, it’s a regulatory violation. Safety-critical systems do not tolerate concept substitution, which is why they always use formal verification.

How to prevent confusion between a bug and a feature

The main tool is clear Acceptance Criteria in every task. AC are written before development begins: “When X is input, the system should output Y.” If the behavior is not described — it’s a bug by default, even if the developer thinks otherwise. AC should be measurable and verifiable: “the button is green” is bad, “HEX #00FF00” is good.

The second tool is a Definition of Done in the team. A clear description of what “done” means: code written, tests written, tests pass, code review completed, deployed to staging, tested by QA. If all DoD items are met and the user still complains — it’s not a bug, but a missed requirement that goes into the backlog as a new feature.

The third tool is a blameless post-mortem culture. If a bug was declared a feature and made it to production — we analyze the reasons, not look for someone to blame. Why did the developer think it was a feature? Why did QA miss it? Why were the AC incomplete? Answers to these questions improve the process, not punish people. Systemic improvements work more effectively than banning the phrase “it’s not a bug, it’s a feature.”