Scott Berkun

Top 100 blogs for software developers

Jurgen Appelo over at Noop.nl put together a list of the top 100 blogs for software developers. My blog, the one you’re reading, slides in at #18, which is surprising given how little I write purely about software development these days.

Happy to be on the list – and if you now realize you hate this blog because of it’s lack of emphasis on making software, you now know where else to go.

How to run a bug bash

Running a bug bash is a dirty secret of software development. You won’t read about them in software engineering classes, or in agile method workshops. But some managers, when overwhelmed with undocumented bugs and not sure what else to do, demand the whole team stop what they’re doing and get as many bugs into the bug database as possible. This is what’s known as a bug bash, and often they’re a waste of time.

It’s true that a proper QA effort, or test-driven development, minimizes the need for this sort of thing, but few software organizations truly qualify. Hell, many so called “first class” organizations don’t have any testers, or a quality assurance plan at all. I bet bug bashes are one of the most common QA techniques used in the world.

And they can be useful – but the most common mistake is doing them by half. A half-assed bug bash sends the message software quality is lip-service. But doing it the right way can turn a project around, raise morale and sharpen a team’s ability to find and manage issues.

How to run a successful bug bash:

• Don’t create panic. If you say “Tomorrow! Everyone find bugs! Aaaah!” You are creating a panic and look like an idiot. You should know a week or more in advance that the bug counts are soft, or the database needs scrubbing, and line up leads and key players to support the effort.
• Freeze the build. You can not do a bug bash on a moving target: you invalidate repro cases and bug findings. Pick a build, freeze it, and make sure no one, NO ONE touches the live codebase during the bugbash. This should go without saying, but you never know. If it’s your first team wide bugbash make sure the entire programming team understands this basic rule.
• Show what good bug reports look like. Remind everyone crappy bug reports create extra work. Provide two bug report examples: one good, one bad. In the good example show well written description, clear repro steps, and a search for duplicate bugs. In the bad, show incomprehensible descriptions, impossible repro steps, etc. If you don’t provide examples, don’t expect people to magically know what you’re looking for. Finding 1000 crappy bugs that need to be heavily cleaned up is a waste of everyone’s time.
• Have an area or type of bug to focus on . Saying “find bugs” is a shot in the dark. It shows you have no clue what’s going on in your project. Think through what the weakest areas are, or what types of bugs you are most afraid of, and designate them the primary goals of the bug bash. Or offer bonus points (e.g. bugs in area 6 are worth x2) for people who find the specific type of bug most valuable to you.
• Clear the afternoon from everyone’s schedule. A bug bash should be an entire team activity and a half-day is the perfect amount of time. Everyone should be working on the same goal: getting good data into the bug database, and getting that database in shape. If it’s voluntary, or only half the team is asked to do it, the bash will fail. People will smell you’re not serious about the effort, and will contribute accordingly. Get permission to reschedule all team meetings for that afternoon to later in the week, and send out a new meeting invite to the team for the entire bug bash time slot. Include details (see below) on where bug bash HQ is, what the prizes are, etc.
• Get support from big shots. Brad Silverberg, my VP on Internet Explorer 4.0, used to file bug reports regularly. When bug bashes started he’d set the tone: everyone gets involved. With the support of leaders it sets the tone of how important the activity is, and eliminates the BS excuses people find not to participate (“If Fred, our best programmer is doing it, I should be doing it too”). Find the key players on your team, either key leaders or the star programmers, and get them to help promote and contribute.
• Have a bug bash HQ. Finding bugs can be a social activity: have a bug bash headquarters. Grab a conference room, order pizza and beer, and invite people with laptops to hang out and find bugs together. This invites people to help each other find repro-cases, share knowledge and bug database tricks, makes keeping a scoreboard easy, and makes the bug bash a proper morale event. A case of beer and few pizzas costs $60. Well worth it.
• Keep score and have real prizes. Geeks are competitive. Use this to your advantage. Any bug database allows queries for open bugs by date: Get this up on a website or hallway monitor and show it in real time. Buy some nerf weapons, dinner gift certificates, or even some X-box video games, and have them visible at HQ – give them away as prizes, or set up a betting pool: $10 per person, and the winner gets the pot. You can get fancy and have special prizes for most twisted bug, the bug least likely to ever get fixed, etc.
• Create rival teams. If you are totally poor, use ego prizes. Have the designers challenge the programmers, or the marketing team challenge the management team. Throw down: “I’ll bet the whole marketing team dinner at Ruth Chris’ my 3 reports can find more bugs than your whole team can”. If you don’t have cash, bet embarrassment: loser shaves their heads, has to dress in costume the next day, has to wash the opponents cars, etc. Get two sets of people who have some built in animosity or rivalry, especially if it’s well known, to openly challenge each other. This rivalry will draw more people in, if only to follow along. Do this once and you’ll have a tradition to build on for the next bug bash.