It's not a Bug, it's a new requirement.

Original article Jeff Atwood

Since I worked on software development and used a Bug tracking system, we have struggled with a basic problem in every project: how can you differentiate bugs from functional requirements?

Of course, if the program crashes, this is undoubtedly a Bug. However, it may only account for 10% of the problems you handle every day. To avoid a project's complete failure, the real killer Bug, which has a Bug that cannot be released, will be quickly eliminated. The vast majority of bugs left behind in the Bug tracking system fall into the gray area that nobody cares about. Is the Bug reported by the user? Not all. Are users requesting a new function or improving an existing function? Not all. Well, what is it?

This is a serious problem. Further, I think most of the Bug tracking systems are "pitfall" us, because they make us have to answer this boring question and force us to stand in the queue-either haifiz, McCays, or Coca-Cola, either Pepsi, Bug, or functional requirement-this is a painful choice, because both are acceptable in most cases. From the user's perspective, there is no difference between bugs and functional requirements. If you want to use a software (or website) to do something, but you cannot do it because a function is not implemented, you have to stop because of an error, are there any differences between the two?

Note: The American drama "Hatfields & McCoys", also known as "blood revenge", focuses on the two notorious American families (Hatfields and McCoys. The dispute between the two families stems from the US north-south war. Anse Hatfield and Randall McCoy were good buddies, but they didn't want to make a change later. They even turned out that both Virginia and Kentucky were not peaceful. As a result, the two families joined hands to create the most notorious bloody dispute in American history.

Let's take an example: when developing a Windows application, Visual Studio does not use the correct font. Is this a Bug or a functional requirement?

I personally think this is a Bug. I guess Microsoft thinks so too (at least theoretically), because the problem has existed in the Microsoft Connect system for more than four years. When you develop a Windows application, unless you deliberately want to use a special font, do you not want to use the default font of the operating system? Well, if you create a new form in Visual Studio 2008 and add a tag control, you can see what will happen:

It seems that you have suddenly returned to 1996, because you see the "cute" MS Sans Serif font. That is the default font of all new forms. Don't be surprised. All new applications look ugly-my wording is restrained!

The following is a comparison: one line of labels uses the default font, and the other line of labels explicitly sets the default GUI font.

Looking at the applications I have used, I found that most Windows programmers do not care about design at all. This is bad! Even worse, this kind of indifference to design is carried by Visual Studio and has been infected with every user since 2002.

Of course, design issues are subjective. In terms of font usage on the Windows graphic user interface, it would be nice if we could have some references! Something similar to a standard. For example, Microsoft defines the user experience specifications for Windows Vista:

• Use Aero themes and system fonts (Segoe UI)
• Use common controls and general dialog box
• Use standard form borders with caution
• ......

There are 12 such regulations in total. However, I want to find the first one: the application should use the system font.

I sighed at the overall quality of Windows Vista, and I wrote a full article about it. The above list looks so happy that it is self-evident. In particular, Article 1: I can't help but laugh when I set aside time to improve the overall quality. When developing Windows Vista, Microsoft is bound to this specification. It is worth noting that these are all from a guy who loves Vista.

Sorry, I ran the question.

Although the window font behavior in Visual Studio 2008 violates Microsoft's design specifications (the first one in this article), this "Bug" has not been corrected for more than four years. It is quietly classified as "functional requirements" and then shelved. After all, there is no negative impact-using incorrect fonts won't crash the program or reduce productivity. On the other hand, imagine how many large companies have developed application software since Microsoft trampled on its own design specifications. Either because the developer is not aware of the mismatch between the application font and the operating system, or they do not have time to write the necessary variable code to correct it.

That's a small problem. I believe that fixing this issue will not make Visual Studio better available, for example, to sell to thousands of large companies for authorization. This is also the reason why it is not in charge.

The problem persists: Is this a Bug or a functional requirement?

I like using UserVoice (this tool is used by Stack Overflow). One of the most exciting points is that it deliberately blurts the line between bugs and functional requirements. In any case, users cannot understand the differences between them. What's worse, programmers may block users. They categorized what they didn't want to do as "functional requirements" and then ignored them. They will argue that a problem reported as a "Bug" is obviously not a Bug, so they do not have to fix it. Let's get rid of bugs and functional requirements!

I hope that we will spend less time in the entire industry to compete for concepts, and do not bother to differentiate user feedback into "bugs" or "functional requirements ". In the face of user feedback, we should spend more time doing something constructive.

It's not a Bug, it's a new requirement.