That's not a bug, it's a new requirement

Ever since I started working in software development and using bug tracking systems, we struggle with a basic question in every project: How can you separate bugs from feature requests?

Of course, if the program crashes, that's undoubtedly a bug. However, that may only account for 10% of the problems you deal with every day. In order to avoid the complete failure of the project, the real killer bugs - the bugs that cannot be released if they exist - will be eliminated quickly. The vast majority of bugs left in the bug tracking system fall into a gray area where no one cares. Are users reporting bugs? Not exactly. Are users requesting a new feature or improving an existing feature? Not exactly. Well, what is it?

This is a tough question. Furthermore, I think most bug tracking systems are "pitfalling" us by forcing us to answer this kind of boring question, forcing us to take sides - either Heifetz or McCoys; either Coke or Pepsi; either it's a bug or a feature request - it's a painful choice, and it's a matter of seconds, because most of the time it's both. From the user's perspective, there is no difference between a bug and a feature request. If you want to do something with a software (or website), but can't do it because a feature is not implemented; is there any difference between the two compared to having to stop in the middle of using it because something went wrong?

(Translator's note: The American TV series "Hatfields & McCoys", also known as "Blood Feud", focuses on the dispute between two infamous American families (Hatfields and McCoys). The dispute between the two families originated from the American Civil War. Anse Hatfield and Randall McCoy were good friends, but they didn't expect that things would change later. The two of them had a feud that even caused unrest in Virginia and Kentucky. As a result, the two families joined forces to create the most notorious bloody dispute in American history.)

Let's look at an example: Visual Studio doesn't use the correct font when developing a Windows application. Is this a bug or a feature request?

I personally think this is a bug. I guess Microsoft thinks so too (at least in theory), because the problem has been in the Microsoft Connect system for more than 4 years. When you develop a Windows application, don't you want to use the default font of the operating system unless you specifically want to use a special font? Well, if you create a new form in Visual Studio 2008 and add a label control, see what happens:

It's like going back to 1996 because you see the "lovely" MS Sans Serif font. That's the default font for all new windows. Don't be surprised, all new applications look ugly - I'm being restrained!

Here is a comparison: one row of labels uses the default font, and another row of labels explicitly sets the default GUI font.

Looking at the applications I've worked with, I've found that most Windows programmers don't care about design. This is not good! Even worse, this disregard for design is carried over from Visual Studio, infecting every user since 2002.

Of course, design issues are subjective. It would be nice if we had some reference material for font usage in Windows GUIs! Something like a standard. For example, the specifications Microsoft has defined for the Windows Vista user experience:

Use Aero theme and system font (Segoe UI)

Using common controls and common dialog boxes

Use standard window borders and be careful with transparent effects

…

There are 12 such specifications in total. However, the first one I'm looking for is: Applications should use system fonts.

I've bemoaned the overall quality of Windows Vista and written a whole article about it. This list is hilarious and self-explanatory. I especially laughed out loud at item 12: Reserve time for "overall quality." Microsoft must have been very bothered by this specification when Windows Vista was being developed. It's worth noting that all of this comes from a guy who loves Vista.

Sorry, I got off topic.

Despite the fact that the behavior of window fonts in Visual Studio 2008 violated Microsoft's own design guidelines (the first of them), this "bug" has remained unfixed for more than 4 years. It was quietly filed as a "feature request" and then shelved. After all, there were no bad consequences - using the wrong font didn't crash the program or reduce productivity. On the other hand, imagine how many large companies' applications have been developed since Microsoft trampled on its own design guidelines. Either the developers didn't realize that the application's font didn't match the operating system, or they didn't have the time to write the necessary workaround code to correct it.

Yes, it is a minor issue. I believe that fixing this issue will not make Visual Studio more popular, such as selling thousands more licenses to large companies. This is probably why no one cares about it.

The question remains: is this a bug, or a feature request?

I love UserVoice (the same tool that Stack Overflow uses), and one of the things that really appeals to me about it is that it deliberately blurs the line between bugs and feature requests. Users don't know the difference anyway, and worse, programmers use it to justify it to users. They classify something they don't want to do as a "feature request" and never do anything about it again. They argue that something reported as a "bug" is obviously not a bug, and therefore doesn't need to be fixed. So, stop distinguishing between bugs and feature requests, and to hell with them!

I hope that our entire industry can spend less time on conceptual disputes and stop trying to distinguish user feedback as "bugs" or "feature requests." When facing user feedback, we should spend more time doing something constructive.

Link to this article: http://blog.csdn.net/happydeer/article/details/40661515