DevOps Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

The Beature: Is It a Bug or a Feature?

  • submit to reddit
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.
Published at DZone with permission of Zac Gery, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)