Believe it or not -- I saw this question posted dead serious at LinkedIn the other day. It made me think, we need to spend more efforts on training everyone to see the negative impact of individual performance measurements.

Have you ever been in an organization where testers were praised for no. of defects found? Though it is harder to measure, wouldn't you agree that it would be more useful to praise people for "no. of bugs that were never introduced due to close collaboration and mentoring of developers"? I need to emphasize that the latter is of far greater importance than the number of bugs discovered.

And here's the important part -- Doing individual performance ratings will seriously constrain peoples innovative abilities, and thus their abilities to do real value stream improvements. In addition, individual performance ratings will encourage people to NOT help each other, even when it is clear it will be of greater benefit for the company.

Promise me you won't do it

By Sune Gynthersen

Creating quality software on a continuous basis is a complicated business.

I think it is a sign of maturity if your team can admit that there are daily problems which are ultimately obstructing flow. While not everyone will appreciate that your team does a complete halt until the obstruction has been removed I think it is a necessity for a team to stay in good shape and continue to deliver frequently.

Just the other day I came to think about what were the most common obstructions of flow we see in software development environments. So here is my preliminary list -- I bet you have seen them all.

1. Build breaks
If you don't have a build, you don't have anything. Nobody is able to do any progress progress as the state of the product is unknown. Developers cannot check-in, as they will not get any response from the continuous integration environment. Testers cannot try out the latest build. Users cannot see the product in action, and the list goes on. A build break is like a blindfold, and you should treat it as such. Don't try to go anywhere until you have your vision back.

2. Test failures
If you have a failing test, you have dysfunctional software. Imaging somebody fitting some cool new styling parts on to a car with a busted engine. Now, who would ever do that? It really is the same with software. Why do any feature work on a software product which has a failing test? I know this can be hard to respect, especially when a deadline is closing in on the team. Deadlines however, does not justify continuing without stopping the line upon test failures.

3. Bug reports
If you have bug reports, you have dysfunctional software. There is no need to do any feature work, until the product is stabilized. Bug reports are even worse than failing automated tests as those bugs can only be reproduced by a human. You should not spend work hours on anything but writing tests for these bugs, and fixing them.

4. Any other blocks keeping the team from a steady flow
If you are experiencing an obstruction which is keeping from moving forward as fast as you could, suggest to the team that you stop doing anymore feature work, until you are able to eliminate the obstruction. One obstacle which I think is quite common is builds that take way to long time. "Yeah, but how can you build 2 million lines of code in less than two hours?" -- Well, I suppose you could start by reorganizing your code and build only the module related to a particular source control check-in. Hopefully you don't have modules consisting of 2 million lines of code!

I'd like to hear about any other obstructions you may have experienced in a software development environment.

By Sune Gynthersen

How do you define quality in a software product? Few defects, no crashes, happy customers?

I believe that software quality really comes down to a few metrics. One is the amount of defects that makes it out of your lab. Another is your ability to maintain the product throughout its life cycle.

The bug metric is one I think most people in the software industry would agree on. So one might ask, why are we still creating them in high volume? Are we really at a point where it is not feasible to lower the rate at which we introduce bugs? I hardly think so. I think developers need a change of attitude towards bugs.

I like to tell myself that for every bug I pass down the "software assembly line" to the testers, I am responsible for the time they waste on finding, reproducing and reporting this bug. Or even worse, if they don't find it I will be responsible for wasting my customers' time.

In case the testers actually find my bug I am furthermore responsible for delaying the entire feature by introducing a need for a "bug fixing phase" where I will be debugging issues that should never have made it into the code.

If I introduce multiple bugs I will most likely also be responsible for wasting somebody else's time on prioritizing them.

I think most developers know that the total cost imposed by defects, rises exponentially over time. But what is really important, is that developers need to accept that they are the key to introducting less bugs, and managers need to accept that trying to push developers to deliver features faster is not going to lower the defect-introduction rate.

What do you think?

By Sune Gynthersen

Reading Lars' article Why Bugs should not be Tracked, and the following discussion on Joel on Software made me think quite a bit about my own view on bug tracking.

Most people in the software industry would probably agree that bugs are inevitable. But consider this -- If the rate at which bugs go into your bug tracking system is higher than the rate at which you are fixing them, you are inevitably up for trouble.

You can either prioritize the same bugs over and over, or close them with a "Won't fix" right away. Prioritizing the same bugs over and over doesn't seem to make much sense for something you are unlikely to fix, as long as the rate of incomming defects is not decreasing.

I am not saying there is something wrong with the bug tracking systems. What is wrong is that we have so many bugs that we need systems to track them and (re)priotize them. The reason I'm quite skeptical about tracking systems is because using them takes away focus from the underlying issue.

Reading the discussion on Joel, it seems that there are those who believe that the human race would not survive without bug tracking systems.

"I have 20 bugs comming in every week -- I need a bug tracking system!". Yes, then you certainly do. At least until you bring the defect rate down to 1 bug a week. You may feel you are in need of a bug tracking system, but what I think you really need is to ask yourself: Why are we releasing so many defects?

I like to tell myself that everytime a bug is found outside our lab, my team is responsible for wasting the customer's time.

If you have a lot of existing defects in your bug tracking system consider the following experiment:

Say you have 300 open bugs in your tracking system. You estimate that 200 of them can be considered important to your customers. How long with it take to fix these issues if you didn't work on anyhing else? Let's say 3 months. Now remove the 100 you won't fix anyway (They will show up later if they really are important)

Use a bug tracking system for the next 4 months only. This gives you 3 months to get the number of defects down to zero, as well as 1 month figure out how to get your defect rate down to one per week. If you can manage to do so your need of a tracking system should have changed.

I believe that if you can...

1. Reduce the rate at which you introduce bugs.
2. Choose to either fix or ignore the legacy bugs you already have.

...You will waste less time on "tracking" bugs, and in time your bug tracking system should become more or less superfluous.

By Sune Gynthersen