thanks in advance = T = the literature

That's not a bug, that's a feature!

The canonical first parry in a debate about a purported bug. The complainant, if unconvinced, is likely to retort that the bug is then at best a misfeature. See also feature.

--Jargon File, autonoded by rescdsk.

In recent times, this phrase has become more of a sarcastic comment made by programmers than an actual excuse one would use in practice. In a real customer scenario, when a bug is found, no one is going to get back to them with "No you see we intended the system to crash when you pressed that key 5 times the way you did..just you know..don't do that next time". It is a sort of self-deprecating joke that comments on just how often certain (unintended) consequences of design decisions are left unfixed because it is too risky and not worth the effort required when potentially no one would ever stumble upon it. It also comments on those times when the code behaves in a way that no one understands and no one can explain. It is one of those things that make new programmers giggle and veteran ones cringe. But, it does also serve as a reminder that programming with careful planning and design will lead to a product with no "surprising features".


The proper response to two different scenarios:

  • The developer did what was asked for, and the product manager or client doesn't think it works as it should: In a very, very old office bulletin board gag, a series of incident reports (complaints to aircraft mechanics) and the responses were posted that were funny or otherwise odd. There was one, for example, that said "Left inside main tire almost needs replacement" with the response "Left inside main tire almost replaced". But the one that gets me to this day is: " Friction locks cause throttle levers to stick." Response: "That's what friction locks are for." In essence, you will get a "bug report" that amounts to "this doesn't do things how I want" or "I cannot do things the way I want", not "this doesn't work". It is indeed a feature, for example, that we have to take so much of your personal information to run a credit card when in theory all we need are all the digits on the front, not even the date. But imagine the hue and cry when people see their accounts empty as fraud becomes much easier. One of the best examples of this was the snooty community that decided to put speed bumps every 30 yards in order to make sure nobody drove quickly past their nice houses, and therefore their calm and serenity were not disturbed. They were VERY angry at the next city council meeting though - they wanted to know why it was taking 911 services like police and fire 12 minutes more to respond to calls. It's not a bug, it's a feature.
  • The manager's being a jerk: Let's say you have a staff that are trying to maintain a sustainable development pace, and have taken on Agile or lean methodologies for any of a number of reasons. And the reason you stick to that is that when you deviate from it it throws off every benefit of the system. The reason software engineers are now to be constrained to 8 hours a day is that it simply isn't productive to work longer. The reason why the eight hour workday was instituted was not out of the gooodness of the factory owner's heart back in the Industrial Revolution, but because the productivity per hour went down the more hours people worked. Even in the Bible it talks about the requirement for downtime. But there's always a manager who seems to want to "sneak it in" or "just do that one thing" or try to game the system to get something for nothing. It doesn't work - you get a temporary boost, but it throws off all your estimation capabilities "what do you mean you can only do X amount of work in 2 weeks, this time you did X+10%!" and means you LOSE productivity in your next sprint. But of course, managers gonna manage, so they'll try any of a number of tricks. When they want something done, some of them will say "never mind sprint planning and capacity and our agreed upon schedule, you're going to have to fix this, it doesn't work". Meaning of course that they didn't specify what they wanted right in the first place, or they got what they asked for, but it isn't what they wanted. But it's not that it's additional work they're asking for, it's that it's a bug, and supposedly working on a bug doesn't "count" - either against time and effort taken away from other activities or in terms of time needed to do.

Log in or register to write something here or to contact authors.