Fog Creek Software
Discussion Board




Motivation during bug fixing phase...


As team leaders, how do you all motivate others to clean out their bugs during the bug fixing phase of a project? We have just completed implementation of our project and are at the beginning stage of the test/bug fixing phase. I see our open bug count slowly climbing each day but without a hard deadline in sight (ship date is still a couple months away) most of the developers have little motivation to clear out their bug list at this point. I thought about setting shorter-term goals for them, like each fixing 5 bugs per weeks, but that seems unrealistic since each bug is different and some will take longer to fix than others. How do you all track this phase of the development process to ensure all the bugs will be fixed by the time the deadline comes? What kind of smaller milestones can I set during this phase? I just don't want to end up having to fix 90% of all the bugs during the last 10% of the allocated time.

ppp
Wednesday, October 23, 2002

Your goal should be to keep the bug count LOW. If it's slowly spiralling up, then you're headed for trouble.

What we did at my last job was set internal milestones. Each milestone had as it's goal some subset of features to be complete, and all bugs marked for that milestone to be fixed. Nothing that wasn't on those two lists were to be worked on.

When we hit a milestone, we'd have a QA day - we only had two full time QA people, so on QA day everyone would do nothing but testing. The person who found the most unique bugs that wasn't their own fault would get a $100 amazon gift certificate. Worked pretty well.

As far as how to motivate - do you have daily/weekly status meetings? Present the bug statistics at these meetings "Joe's got 10 bugs, Jim's got 30 - you might want to try and fix some of those, Jim..."

Chris Tavares
Wednesday, October 23, 2002

I've never understood developers who hate fixing bugs. For me, the idea that my application is getting more stable and robust with every bug I fix is very satisfying.

As for your developers. Are they doing new projects as well as bug-hunting in this existing one? If so I think that's a mistake. The old project will always be the second priority.

If they're unmotivated by bug fixing make the point that they're not going to get to do any new stuff until the old project's out the door.

Also, maybe they're unmotivated because they feel they're just applying hacky bandaids to a flawed design. If you've still got a few months it might be possible to do some disciplined refactoring to get the bug count down and the motivation up.

Andrew Reid
Wednesday, October 23, 2002

Bug fixing was my favorite part of the development cycle.  You can taste the completeness.  You become a machine, ticking off one bug after another.  There's nothing like fixing 5 trivial bugs in one shot.  etc etc

Bella
Wednesday, October 23, 2002

"how do you motivate others to clean out their bugs during the bug fixing phase of a project?"

Good developers are usually self motivated about this.

Assign one bug fix per developer, ask a few times a day "is it done yet?", after a reasonable time say "why not?".  Listen to the answers, react accordingly.

If a developer has too many bug fixes assigned to them they can easily "hide" under the shadow of the mass of them when being asked about any one of them. This is a normal human trait and applies to all sorts of work not just coding.

Alberto
Wednesday, October 23, 2002

We'd discuss & assign each bug to a developer during our meetings.  I used to keep a bug log in MS-Access (KISS), and print a report for each developer with his assigned bugs.  People then continually fixed their bugs as testing progressed. 

There should be NO MOTIVATION needed for this to happen.  A developer WANTS his code to be working right.  Go find bugs, I'll fix every damn one of them before you can say "status=ready for retest".  It's a great feeling to fix a bug before the tester is hardly done telling you the details.  It's called THE ZONE. 

Whoever is not fixing his bugs is a HUGE RED FLAG.  Either he knows his code is fucked, or he is super lazy, or simply doesn't give a shit about the outcome.  Either way, flush those people, they are bad news.

Bella
Wednesday, October 23, 2002

The fact that you're asking this question is very alarming. It seems as though your developers have been chugging away for months implementing new features or designing the GUI or whatever, without fixing the bugs as they crup up.

Now you've got to hunt for bugs and try to fix them. It's probably been months since some parts of the code have even been touched, and locating bugs in that section of the code will be very painful.

Bugs should be fixed the _second_ they're identified. Because if you've got bugs lurking in your code and you build new features around those bugs, there's always the chance that fixing the bug will break other features that were working correctly.

My advice: you should not have a "bug fixing stage" of the project. You should be fixing bugs every day.

Benji Smith
Wednesday, October 23, 2002

I always find that putting a colour-coded print out of the open bugs on the wall helps with motivation. Red, orange and green (red being the most major). Even though we use bug tracking software it's still nice to walk up to the list and cross bugs off it. You get a sense of progress.

As for specifically assigning bugs to people - I find that demotivational as you can feel you're on your own trying to climb a mountain. I prefer when everyone can pick up any bug they like - more of a team effort, all in this together. Of course that wouldn't work if you have a team of slackers who pick up all the "This menu item has a typo..." type bugs leaving you with the unreproducible crashes!

John C
Thursday, October 24, 2002

"I prefer when everyone can pick up any bug they like"

We usually do this in meetings, everybody says which bugs thay want and we assign them. Then they have an "owner". This works very well for a motivated team.

Alberto
Thursday, October 24, 2002

I'm guessing that one of the following possibilities may be true:

1. The people you're trying to motivate are not the same ones who started the project or architected the project.

2. They weren't given the freedom to implement as they saw fit using their best judgement (really same as #1, only different).

3. You're heavily tied into some 3rd party software which is giving you fits.

4. You've told them "fix it but don't change anything".

5. You've got truly crappy developers.

6. You live in Seattle.  It's a epidemic here: developers don't fix bugs because "it works fine in my office".

Nat Ersoz
Thursday, October 24, 2002

I always find that bugs proliferate most when there is a strong blame culture. Remove this, (along with the equally errant reward culture) and you get developers who want to fix bugs out of pride - free from fear of persecution or sacking. Obviously you need to manage it etc, but I think good developers will be motivated simply by the desire for good, solid, stable code.

I know from personal experience that if you're scared for your job, or public humiliation (let's face it we all write bugs), then you won't admit to it and therefore you won't fix it.

Sam Strachan
Thursday, October 24, 2002

"We'd discuss & assign each bug to a developer during our meetings.  I used to keep a bug log in MS-Access (KISS), and print a report for each developer with his assigned bugs.  People then continually fixed their bugs as testing progressed. 

There should be NO MOTIVATION needed for this to happen.  A developer WANTS his code to be working right.  Go find bugs, I'll fix every damn one of them before you can say "status=ready for retest".  It's a great feeling to fix a bug before the tester is hardly done telling you the details.  It's called THE ZONE. 

Whoever is not fixing his bugs is a HUGE RED FLAG.  Either he knows his code is fucked, or he is super lazy, or simply doesn't give a shit about the outcome.  Either way, flush those people, they are bad news. "

^ ^ ^ What Bella said. 

Norrick
Thursday, October 24, 2002

Another great way to motivate is to sit down with developers and pair program, in this case debugging. A person is more likely to become motivated if there is someone sitting right beside them. And sometimes pairing helps you find bugs a little quicker. It's not hand holding, you can move on to other developers, but it helps.

Ian Stallings
Thursday, October 24, 2002

I usually find that the paycheck that gets deposited in my account every 2 weeks is motivation enough to complete the work that is assigned to me.....

apw
Thursday, October 24, 2002

I think simple embarassment for being the source of the bug is a major anti-motivator.  Blame culture or not, folks can't ingore the bug producers and the nature of the bugs produced. "Ignore that man behind the curtain."

tk
Thursday, October 24, 2002

Follow some simple rules.

Every bug is assigned to a developer.

A developer with an open bug assigned to them may not do anything else until it resolved.

Bugs are prioritized, higher priority bugs must be cleared first.

If you entered your testing phase with open bugs then either your development methodology or your project is in deep trouble.

I find it hard to believe your would rather test than fix bugs.

Anonymous Coward
Thursday, October 24, 2002

First, it's too late to make the fundamental change it sounds liek you need. Maybe you can apply some changes to your next phase or next project.

To do this, first go read The Joel Test:

http://www.joelonsoftware.com/articles/fog0000000043.html

In section 5, it explains why you should always fix any known bug before writing new code. (The caveat here is that there may be bugs that you decide are obscure enough that you can live with them in the final release. See Joel's Hard Assed Bug Fixin' article for more details on that: http://www.joelonsoftware.com/articles/fog0000000014.html )

What we do at our company, which seems to work quite well, is this:

--> 1.  Engineer writes all code for a "deliverable" piece of functionality.

What we define as "deliverable" is some unit of functionality that is isolated enough that it can be tested on its own. Typically, the time frame to complete this "chunk" is around the 3 to 5 day mark.

--> 2.  Analyst who wrote the requirements sits down with the engineer and does an "ad-hoc smoke test."

We find this really helps avoid churn between the formalized QA staff and the engineering team. Why? Because the most annoying thing a seasoned QA person can experience is a bug within 5 seconds of running the program.

Why didn't the engineer pick up on it? He or she was probably trying to get some other part of the feature working and simply didn't do the series of steps that the QA person happened to do first. Or, the engineer may have either missed a requirement or misinterpreted a requirement.

This is what's great about it. Within about 15 minutes, the analyst can "play with the feature" in an informal setting, RIGHT AT THE ENGINEERS DESK, and nail a whole bunch of obvious things. She then writes them down and the engineer just dives right in and fixes them. The benefits are a) the bugs are discovered and fixed extremely close to the time they were written, b) the analyst can be sure her requirements are being interpreted correctly (and make her own "fixes" if they are confusing), c) the QA person focuses all the time and energy on finding the DIFFICULT bugs, not the easy ones.

Another huge benefit is that the overhead of tracking the "easy" bugs in the formal bug tracking database is eliminated. Overhead goes WAY up once the feature moves to QA.  You have the time involved with entering the bug, including steps to reproduce. You have the time involved in the engineer going through the database, as well as asking questions if he can't figure out how to reproduce it. And finally, there's the overhead incurred by the delay between when the engineer wrote the code and fixing the bug, which means it's going to take more time for him to fix it.

--> 3.  Engineer fixes all of the bugs the analyst found

--> 4.  Analyst re-tests the fixed bugs, then tries to break the "deliverable" again.

--> 5.  If any bugs found, go back to step 3.

At this point--and this is the important part--the deliverable DOES NOT GO TO QA until all of the bugs are fixed. (Again, the one caveat is if there are any bugs so obscure that the time to fix outweighs the benefit of fixing them, but those types of bugs typically aren't found during this ad-hoc type of testing.)

--> 6.  Feature is sent to QA

--> 7. QA finds bugs and enters them into bug tracking system.  Engineer is e-mailed the bug report.

--> 8.  Engineer checks e-mail a couple times a day. If there are any bugs, he fixes them IMMEDIATELY, before going back to writing any new code.

The bottom line, as Joel says:

    Fix all known bugs before writing any new code.

Dave
Thursday, October 24, 2002

I like the idea of code ownership.  Programmers take ultimate accountability for the quality and performance of their code and are responsible for fixing all bugs in it.  Bugs are only assigned to the owners of the code where the bug resides.  If it's not immediately clear which part of the code is responsible for the bug, take an educated guess.  This also enforces the natural selection process of programmers whereby the programmers producing the most buggy code will be spending most of their time fixing bugs instead of writing new code.

Brian
Friday, October 25, 2002

*  Recent Topics

*  Fog Creek Home