"Feature request!!!"It's often the battle cry we software engineers use to downplay the urgency of a customer's issue. After all, there isn't time to add in new features when we gaze out at the never-ending bug log that faces us.To us software engineers, the difference between a bug and a feature request is crystal clear. A bug is a discrepancy between how code is actually working and how our code was intended to work. A feature request requires new code to satisfy a case that can't be handled by the current codebase.This kind of thought-process always leads us to the more general question of how software like DoneDone should be used. Should your organization use one type of software to log bugs, another type of software to manage upcoming tasks, and yet another type of software to track feature requests?
The age old question...We spend a lot of mental energy trying to sift through issues logged by a client or customer, trying to determine whether we throw an issue into the "bug" bucket or the "feature request" bucket. For consulting work, when we're working off of a pre-defined agreement of how software should behave, this makes sense. Feature requests might require an extra charge.But, when it comes to just the pure practice of building good software, particularly if we're working on our own products, how much should we care about categorizing an issue this way?
Robert Martin (a.k.a. Uncle Bob) talks a lot about software. He considers the Web merely a delivery mechanism and nothing more. It is not the end user experience, and it is not the purpose of the software. It's simply a tiny little dumb detail. Yet, when we programmers program, the architecture of our applications is too entirely influenced by the fact that it is a Web application.
Uncle Bob says to let go of the dumb detailsIn the same way, what if we considered the term we use for "a thing that needs to get done" to be a dumb detail?From the point of view of the person logging that "thing," does it really matter to her that she's requesting a new feature versus discovering a bug? She just wants her problem solved by another human being, and preferably, to know when her problem might be solved.You might be able to see the technicality more obviously if we leave the software world. When the plumber comes in to fix the leaky shower, I'd imagine you don't care about the detail. If the shower head was incorrectly installed (bug) or if the gasket is broken (bug) or if teflon tape was missing from a cheap pipe (feature), all you care about is how long it will take to fix and how much you'll be charged.
Last week We Are Mammoth released Kin, an HR software tool for small businesses. Kin gives you a simple way to track each employee's time off requests. One thing Kin doesn't do right now is distinguish weekends and holidays from work days. So, if you wanted to take off a full week during Thanksgiving, you need to manually enter the amount of hours that you're requesting off.The team has already received a few requests to have Kin do this tracking automatically. In fact, it's in the release queue. But, when it's logged, in whatever place it's logged in, should the Kin team consider it a bug, a feature request, a task, or a to-do?Calling my inner Uncle Bob, my answer is simple: It doesn't matter how you classify the request. It's just a dumb detail.That's not to say we shouldn't classify it at all. The Kin team might tag the issue under "feature request" and work on fixing more critical issues first (like a user with an authorization problem). That's fine and dandy, and a valid approach.However, it would be a mistake to automatically assume all things-we-call-feature-requests are less urgent than all things-we-call-bugs. That's making the rather minor detail of how we classify the issue the centerpiece for when we resolve it. It shouldn't be that way. At the end of the day, all of these requests are simply things that need resolution.
To that end, the label we give to all of these requests is largely unimportant. What matters more is that someone is attending to them and there is a general idea of when these requests will be addressed. What matters more is that 33% more users will benefit from Item A being addressed versus Item B. Regardless of what type of thing Item A or Item B is, Item A is a more valuable to address. That's it. Nothing more.So, next time you're spending too much time with categorizing tasks, bugs, feature requests, and to-dos, remember to forget the technicalities. They're just the dumb details.Sign up for a DoneDone account in 30 seconds. Want to read more by Ka Wai Cheung? Ka Wai’s new book on the modern-day programmer, The Developer’s Code, is available in eBook and print. You can follow him on Twitter @developerscode.
