I guess this distinction is based on the assumption that the implications of fixing a bug tend to be "local" (i.e.: affecting smaller parts of the program) where-as those of implementing a feature tend to be "global". Thus, implementing a feature is more likely to introduce new bugs, so it makes sense to postpone it until most current bugs are solved.
I disagree with this thesis.
First, I saw many bug fixes that resulted in new bugs being introduced, thereby contradicting the "locality" assumption.
Second, in a test-infected program (that is: a program with a strong test suite), the chances of unwanted side effects being introduced due to a feature implementation are practically zero: you write the code, you run the tests, and if the bar is green then everything is likely to be fine.
One final point: It seems that this distinction, along with several other (mis)conceptions came from the Waterfall approach: With development and debugging being two separate phases it is only natural to classify the items on the project's to-do list as being either a feature or a bug.
Eclipse for example are using Bugzilla for both bugs and feature tracking and see them both as equal citizens. By the way, Eclipse has as of now about 37K open bugs and it is still considered a good piece of software (not mentioning the JVM's open bugs). Sometime you just have to keep going and ignore bus that might drag you down. As Guy say in his The Art of Innovation post: "Don't worry, be crappy" :-)
Eishay Smith
November 28, 2008 at 10:37 AM:) Great slogan
Unknown
November 29, 2008 at 1:16 AM