Click here to Skip to main content
13,625,905 members
Click here to Skip to main content
Add your own
alternative version

Tagged as

(untagged)

Stats

3.6K views
Posted 19 Jul 2013
Licenced CPOL

The Beature: Is It a Bug Or Feature?

, 19 Jul 2013
Rate this:
Please Sign up or sign in to vote.
"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.
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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author


You may also be interested in...

Comments and Discussions

 
-- There are no messages in this forum --
Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web04 | 2.8.180712.1 | Last Updated 19 Jul 2013
Article Copyright 2013 by Zac Gery
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid