>One of the things I have learned over the years is that sometimes we are overly worried about performance, when we should be working on fixing bugs. The later may help take care of the former. I do believe that performance tuning probably needs to be incorporated into every other iteration or milestone, just so that you are not degrading the overall system. With that said, I think fixing bugs is a higher priority.
Bugs are what your user community and adopters have to deal with. They affect the overall quality of your code, and make life miserable for everybody. Nobody likes to do bug fixing, so that is another reason to adopt Unit Testing and making sure that your code is architected so it is testable. That means making sure that all your classes can be tested. Every class in theory should have a test. This means not scoping your classes to package only. You can get around some of the package only scoping by including your tests in the package, but this is just plain ugly. I have yet to hear of a good argument for package scoping a class.
Classes and code that are hard to test makes it difficult to debug. Which then makes it more likely that bug fixing gets pushed to the back burner, over the cool new code or feature that is to be written.
There are some projects that do a better job than others. EMF is an example of a popular project with high visibility that does a good job on their bug backlog. Currently there are 65 bugs that are open. The oldest bug is a little over a year old. In this case a bug is anything that isn’t listed as an Enhancement priority in bugzilla.
Compare this to PDE which has over 805 bugs open. There may be a very good reason for the number of bugs being open. I leave that to the PDE team to be the judge.
Most of my eclipse coding effort has been concentrated on XSL Tools over the last year. XSL Tools has about 10 bugs. I try to have the team make it a priority to address bugs before enhancements.
Addressing the bugs and making your code testable is a critical piece of software development. It may not be the most glorious thing, but it’s important. The more bugs you fix now, the more new code you can write later and not have to worry about those old pesky bugs sitting around. You can get to performance tuning and enhancements after the bugs are fixed.
intellectualcramps 
>David, I gave it a try in my 3.5 IDE but it failed to work at all. At the end of the analysis it only printed out something about “Happy collisions for Xyz.java”. Is it a late April joke? 😛
>Eike, which program were you trying to run? As this entry was just about fixing your bugs before moving on an doing enhancement work.
>By that logic, JDT with its 3600+ bugs open is in trouble.In EMF, Ed does a really good job of separating out bugs versus enhancements. In essence, most things are considered enhancements ;)In other projects, the distinction isn’t as clear.
>@Chris: You hit on a very good point. How well a project triages their backlog will make a difference in what is a bug and what is an enhancement. I would say that most things start off as an enhancement until they are implemented, once a feature has been implemented, and there are problems discovered, then that new report is a bug.Better triaging of the backlog is something that all projects need to do. Again though it isn’t something that many like to do. And in my opinion, 3600 bugs is a concern.How many of those 3600 bugs are being addressed in e4?
>Nice tips, to fix bug first