![\"\"](\"https:\/\/colorsinprojects.ro\/wp-content\/uploads\/2023\/05\/feature.png\")
<\/p>\n<\/p>\n
Are Poopy Diapers a Bug or a Feature?<\/strong><\/p>\n The number of poopy diapers we had to deal with in the baby\u2019s first couple of months shocked me. Did I have a buggy baby? Or were these diapers an undocumented feature?<\/p>\n I didn\u2019t think too much of it at first, but after some time I had a disagreement with a developer on whether a bug submitted by the QA team was a bug or not and I asked myself the wider question:<\/p>\n When is a bug a feature request and when is it a reasonable expectation of a user story?<\/strong> A Software DEFECT \/ BUG \/ FAULT is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectation (which may not be specified but is reasonable). In other words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect\/ unexpected results.<\/p>\n The part that resonated was \u201cend-user expectation (which may not be specified but is reasonable)\u201d, but that\u2019s probably because I\u2019m the one writing the software requirements in my team.<\/p>\n Dalip Mahal argues that a defect only exists if code behaves differently than the requirements specification, his argument being that many organizations do not create sufficiently complete requirements before starting development.<\/p>\n He further argues that incomplete requirements and unrealistic deadlines force developers to take decisions about how to implement features which inevitably result in bugs.<\/p>\n While this is true on some projects and in some companies and probably more so when using waterfall methodologies, it also sounds like a blame game. Where the developers blame the business analyst that an outcome was not specified while the business analyst claims that the expected outcome was obvious and did not need documenting.<\/p>\n Thinking back to the disagreement my colleague and I had, I tried to understand why we had debated so much on whether the issue found was a bug or a feature. And then I found Jeff Atwood\u2019s article That\u2019s Not a Bug, It\u2019s a Feature Request<\/a> that raised two really interesting points:<\/p>\n There\u2019s no difference between a bug and a feature request from the user\u2019s perspective.<\/strong> That\u2019s when it struck me: I thought our baby was buggy because I didn\u2019t want to change the poopy diapers!<\/p>\n Another reason we tend to have the bug vs feature debate is ego. BAs don\u2019t like to hear that they haven\u2019t covered everything in their user story and acceptance criteria so they tend to say \u201cit was implied\u201d, while developers don\u2019t want to admit that although not explicitly stated, it\u2019s reasonable to expect a certain outcome to be covered by a user story.<\/p>\n Then there is the whole planning and prioritization discussion. People assume that if they submit a bug on an incomplete functionality it will be done sooner than if they submit a feature request to do the same thing.<\/p>\n Here, I really agree with Ernest Mueller\u2019s opinion<\/a> that, in an organization where the focus is on the end users, no one should really care whether something is a bug or a feature as long as it brings value to the end users.<\/p>\n So, the next time you find yourselves having this debate ask yourselves:<\/p>\n Does it really matter if it\u2019s a bug or a feature?<\/strong>
\nTo answer the question, I first searched for the definition of a bug. There are plenty to be found, but this definition from Software Testing Fundamentals<\/a> resonated with me:<\/p>\n
\nBut, by having this dichotomy of bug or feature it pushes some developers to label things they don\u2019t want to do as feature requests, in the hope that these new features might never get done.<\/p>\n
\nJust get it done and bring value to your customers!<\/p>\n