All seasoned developers have run into the infamous question "Is this a bug or a feature?" These "beatures" fall into a gray area and come from a variety of sources, including customers, sales people, developers, QA analysts, or anyone with a bit of tinkering knowledge. Once the observation has been communicated to a development team, the discussion/arguing begins. Labeling a concern as a bug or feature request can completely change its complexion. Companies have specific processes in place for production issues. Some have dedicated teams, while others interrupt new development. If something is labeled as a feature request, it generally falls to a completely different team. This group, usually a product/project manager or business analyst, must research and prioritize the request amongst a sea of other needs. In some situations, a witch hunt can commence to find the reason for the beature. This is unnecessary as many different constraints ultimately led to the outcome. For instance, moving too fast, inexperienced developers, or complex programming structures can all lead to unintended functionality. Although this is an argument for the ages, are we having the right one?
To clarify, this does not include intentional easter eggs or back doors. Programmers love to use the statement "It's not a bug; it's an undocumented feature," but this discussion needs a new perspective. How about... it doesn't matter. Some beatures might be intentional while others are not, but that is still having the wrong conversation. The bigger question is "How should or would you like it to work?" This might sound like a loaded question, but it's an important ice-breaker to get the conversation started and focused. The question of bug vs feature is irrelevant to end users. They have a problem and are looking for an answer/resolution.
Unfortunately, defining something as a bug or feature is an internal business process that has gone awry. It never should have been made public. Classifying something as a bug or a feature is important for internal development tracking systems. They help document and track development efforts in a systematic manner. These systems help clarify the health and direction of software development. Although these are vital to any organization, it's important to remember that behind each beature is a real person. Sometimes developers can fall prey to process and loose sight of the larger picture. As good stewards of software development, programmers should strive to provide the best experience possible. This can be accomplished through a servant mindset and good business decisions. End users are the reason that development exists. It's prudent to respect their time and needs. Nobody wants to develop the software people used to talk about.
