Bug Bash

It’s been a while since we organised a “Bug Bash”. The general idea is to focus on fixing software bugs and clearing the seemingly ever-growing list. Sometimes managers have organised this as an optional thing over a weekend, or sometimes opted for a work week.

The problem I have with this idea is that with a strict deadline, you are encouraging people to rush. If you want to follow the usual process of a developer really understanding the bug (reading the bug report carefully, recreating the issue, analysing the code, coming up with a solution, testing it manually, maybe writing some unit tests for it), then going through the code review and testing process – then you are being really hopeful that it can be done in such a strict time-frame.

I find another developer will always have some opinion on your code, so you make a change, have to retest it and then get them to review it again. Then when coming to patch it on the test environment, you then might get problems with the build server or the test environment.

So the only bugs that are really appropriate for a Bug Bash are ones that are easily recreatable, quick to fix, and low impact. All the true high priority issues will have been addressed more urgently and put into the normal release process anyway.

What you have to bear in mind, is any change has some kind of risk that you might introduce another problem, and this increases when you try and rush the change out; which is what the Bug Bash inherently prioritises.

I was looking for an example of how managers sold the idea, and I found one that actually seemed a bit more thought out:

 
Next week we are to down tools on project work and spend the week stabilising our product.
 
Service have provided a list of 300+ issues they would like us to work through. In addition, Paul has been reviewing the Error Logs to identify the most frequently reported errors and is creating items for these.
 
The domain experts are currently reviewing the list and identifying the issues they feel can be fixed next week. These will be placed into the Stabilisation list.
 
The priority order for working these items is set by a temporary field ‘Bug Fix Priority’. 1 is the highest priority.
 
Each developer should select the next bug at the top of the list that is not currently being worked, change the state to Assigned, and Owner to themselves.

All Priority 1s must be completed first. If there are no defects you are comfortable fixing, please speak to me before moving on.
 
Each bug fixed must have supporting unit test(s) before being sent for code review.
 
At no point should a developer have more than 3 items they are involved with, this being 1 bug being worked on, 1 being code reviewed and 1 with the tester.  If you’re waiting for a code review - go chase it. If you're waiting for a test to complete – go help out.
 
It is important to note the emphasis on this release is QUALITY.
 
With this in mind, the attached spreadsheet has been produced that maps a developer to someone who will review their code and DB changes. Where possible we have also mapped each developer to a test resource. The developer and tester jointly own the end to end process for each bug.
 
A kick off meeting will be held at 10am on Monday in Room 1 for all to attend.
 
Code Reviewers will hold daily stand-ups with their development and test resources which will then feed into a management review at 4 pm.
 
 
Darren
Development Manager

So, they have allocated a full week, tried to analyse the bugs to see if they are suitable to fix quickly, and they have emphasised it is about quality. However, they seem fairly strict on the order the bugs are addressed, so you may end up with developers being forced to pick up items in areas they don’t specialise in.

There was a follow-up email stating that there were issues with the build server which caused them to lose time.

All,
 
The plan is to finish coding tomorrow to allow test to complete on Friday.
 
With this in mind and as a result of build issues experienced yesterday we’re considering the possibility of overtime tomorrow evening to make up lost time.
Can you please indicate using the voting buttons by 12pm tomorrow whether you’d be available for overtime tomorrow evening.

We'll be ordering Pizza and a Beer too, to keep us fuelled 😉 It would be very much appreciated if you could stick around. Every bug fixed is giving our end users a better customer experience!
 
Thanks,
 
Darren

When Bug Bashs have occurred over the weekend, I think Developers and Testers have started at the same time, but they wouldn’t have had anything to test until mid-day at least – due to development time, code review time, then build and patch process. So the Testers will just be earning money for chilling out and eating pizza.

I found an instant messaging conversation with a colleague about a different Bug Bash:

Daniel 11:37:
one of the bugs on the list to be fixed in the bug bash was logged by me 5 years ago
so very urgent then

Me 11:38:
the bug bash isn't supposed to be for urgent issues

Overtime requests will only be approved for time spent on defects that are Fixed, Tested, PO Approved and Closed(Done)
 
So you could do some complex work, not get it done, and therefore not get paid

Daniel 11:42:
yeah I read that today
who's going to go for that
it's completely the wrong way to fix bugs

So this bug bash seemed to be for clearing down all the bugs that have just been ignored for years. The problem with old bugs like that is that you could spend time trying to recreate them, and find they are now obsolete due to other code changes, or obsolete features. The managers also decided they didn’t want to pay people for incomplete items, so you cold spend ages working on something and not get paid.

• You could close the bug as obsolete – it’s not fixed so you don’t get paid
• You could spend ages recreating it, coming up with a fix, but there’s not enough time for the rest of the process to actually complete it.
• You could come up with a fix, but there’s a small bug found by the tester. You could persuade them to keep quiet so you both get paid.
• You could come up with a fix, but build issues cause it to not get tested.

I think that every-so-often, you do need to analyse the list of bugs you have, and try and clear it down; either by fixing them, proving they are obsolete, or maybe just marking them as never intending to fix. A dedicated period of time is required but I would have thought a 2 week period is required at minimum in order to not cut corners.