Fix Bugs First

The Fix Bugs First principle of fixing bugs before implementing new features is a somehow simplistic yet efficient way to deal with projects suffering from CreepingFeaturitis.

CreepingFeaturitis

CreepingFeaturitis is a disease where pressures from the management and pleasure of some creative developers lead to an increasing number of features that are partially implemented, quality being the boring aspect that is deferred. CreepingFeaturitis typically occurs when there is no clear prioritization of work and when the team does not know what would make a customer happy. This is often due to the lack of customers, i.e. typically when the software is not ready to be sold yet.

Brutal form

In its most brutal form, Fix Bugs First means that development of new features should stop immediately when a bug is discovered. The team must then take care of known bugs before adding complexity to the software. As a result quality of existing features increases. And the team start regaining some credit.

Subtle form

In a more subtle implementation of the principle, bugs and features are constantly prioritized based on the perceived importance for users, schedule and cost to fix, so that a conscious decision is made to fix a bug or implement a new feature either now, later or never, depending on what makes most sense at the economical level.

Challenges

Successful implementation of the principle typically requires BugTrackingSoftware (a well-agreed definition of what is a bug/feature is a plus) and support from some key people in the organization.

How to build such support in an organization is yet to be discovered... -- JeanHuguesRobert

It could be that Fix Bugs First is another name for FixBrokenWindows. The latter is more about motivating people by building an environment where QualityMatters?.

Alternatively, one may have some good points to justify the fact that in most cases lots of known bugs are not fixed quickly (if ever), or at least provide some clues about why it is so common. -- JeanHuguesRobert

After some research it appears that the Fix Bugs First principle has been applied successfully on different occasions. One of them is described in http://www.controlchaos.com/Case1.htm as an illustration of the benefits of the ScrumProcess, one of the AgileProcesses that goes together well with ExtremeProgramming. -- JeanHuguesRobert

Add other successful applications of the Fix Bugs First principle here (failures are welcome too).

I would propose an alternative. Do what the customer wants most, regardless of whether it is a bug fix or a new feature. We want to get as much value out of the time spent developing software and stay away from arbitrary definitions of "bugs" versus "features." I've seen too much time wasted on those arguments.

I disagree. When an implemented feature goes from working to not working there is no question as to whether it should be fixed. Asking the customer whether they want that feature to move back from not working to working again would be embarrassing, as well as implying a certain level of incompetence, or even extortion on the part of the developers. -- EricRunquist

Unfortunately, there are various degrees of "not working". Showing a number with 3 decimal points when the customer wants only 2 is definitely a bug. Displaying a dialog with a cyan background when the customer wants light green is also a bug. A button placed on the left side when the customer wants it on the right is also a bug. Would a customer prefer to have a dozen of these bugs fixed or have another new feature enabling him to automate more of his business? You will have to ask to find out.

It is very simple to define "working" vs. "not working" if you have a build system with some automatic build (regression) tests. With each new implemented feature you add a very small test to verify it works properly. A build is considered "failed" if (a) either the build process itself (e.g. executable generation) stops or (b) the build regression test (with the generated executable) fails. And these "build fails" have highest priority. This not only ensures your bugs are fixed first but also that they don't come back. (For large projects, more extensive testing can be done less often than a daily build by doing a regular "System Test".) ---AnonymousDeveloper?

I think FixBugsFirst is merely a symptom of problems arising from elsewhere, not an effective project management strategy.

Typically if your customer communicates a requirement to you, it should stay communicated, and failure to satisfy the requirement is always a bug. Thus, all new requirements are actually bugs, since the project probably doesn't satisfy them until after some new code is written to bring the project back into compliance with its requirements. CodeUnitTestFirst makes this explicit in code. Old requirements will remain in effect until explicitly superseded by new ones.

If you had sufficient time and resources, you would always fix all the bugs, including recently added or superseded requirements (what some might call "new features"), and it wouldn't matter what order you do these in because they would all get done on time. Everyone will be happy, and in your spare time you could visit a Wiki or something.

Prioritizing bugs over features (which is really just prioritizing one set of bugs over another set of bugs) is a tactic which you use when you discover too many bugs and not enough time or other scarce resource available in your schedule to fix them - in other words, you find yourself in a crisis situation where your schedule needs adjustment. Obviously the customer should be involved in (or at least informed of) any changes in project schedule, and the customer can help you derive a new schedule which commits resources to the most important bugs first.

If you look at the above backwards, you get FixBugsFirst - a practice where you avoid the schedule crisis in the first place by simply preventing the customer from modifying project requirements before fully satisfying all the existing ones. This seems like a very bad idea to me, assuming your customer is sane and can make rational decisions based on good information about the current state of the project and its existing requirements. If your customer is insane, then you have larger problems than buggy code. -- ZygoBlaxell

OffensiveProgramming has more applicable comments.

I recently saw a BugDrivenDevelopment?, BDD, joke about BehaviourDrivenDevelopment (BehaviorDrivenDevelopment), BDD, a descendant of TestDrivenDevelopment, TDD. It reminded me of my FixBugsFirst style of development in the nineties. -- JeanHuguesRobert