Some Thoughts on Bugs

The proper application of test-driven development yields in fewer bugs. This experience is share by quite a few people in the agile community. Still, there are bugs. This is not because your engineers have relaxed their quality standards. I think it is because expectations are higher. Customers can be more picky.

A few years ago people didn't dare to demonstrate software if it was only a few days old. After all it didn't go through a proper testing cycle, right? And to a degree - in particular in more traditional organizations - they were right. Quality was poor in some cases. Crashes could enrage even a mild mannered reviewer. But even if it wasn't a crash, bugs tended to be quite substantial in their impact. So showing the software created more uncertainty rather than excitement.

In a newer environment it is possible to show "brand new" software. Depending on your environment "new" means it's just a few hours or days old. Or just take the latest successful build.

When I look at some of the bugs raised today I see that they fall into the category "aesthetics". In the past people wouldn't have bothered raising them because compared to others they would have been negligable in terms of severity.

Does that mean that we should be happy about this? I don't think so. A bug is a bug is a bug. We shouldn't be proud of any bug. Each bug is an indication of a piece of unfinished work. If some bugs are a question of taste then it might be we will never be able to reach zero defects. In that case we should at least see this as an ideal towards which we work. Toyota - despite it's recent hickups (recalls of vehicles, even Lexus) - is seen as the well-recognized quality leader in the automative industry. Does this mean their products are defect free? No, not even close. They are subject to Murphy as well. But they have their unique way of dealing with them. They fix them one at a time. And not only that. They also try to identify ways of how to avoid the same defect from reappearing.

So where from here?

We should take Toyota's behavior as an example. We should still strive for reducing defects wherever we can. And we should do so by avoiding them in the first place. Communicating and collaborating closely with the customer is one of the first and most important steps. Writing your tests first and use them to drive your implementation helps, too. Keep your code simple, readable and maintainable.

And with bugs: Each time one slips through, follow these guidelines:

1. Try to understand the root cause for the bug. Prove your understanding by writing an automated test that fails because of the bug.
2. Make the test pass.
3. Refactor mercilessly.
4. Identify similar scenarios in your code base. Check whether they contain the same bug. If they do, chances are that you have identified another opportunity for refactoring.

Here is another aspect of bugs. Compare a bug to an ordinary story in your backlog. What is the major difference? Generally speaking, a story tends to be easier to estimate in particular if it is similar to a past one. A bug can be anything from "user misunderstanding" to "several weeks" of work. The point is that the amount of uncertainty tends to be higher for bugs.

So if you compile a single, consolidated list of all your work items, you will end up with a mixture of stories and bugs. The larger the proportion of bugs the higher the uncertainty. The higher the uncertainty the bigger the impact if one or more of the bugs require more than the "average" fix time.

So if you are interested to become more reliable (read predictable) then the suggestion is to keep the bug level as low as possible.

Does this mean you can't have crash parties any more? Under all circumstances, if the crash party helps you to assess the quality of your product and helps you to find more bugs, and you if you see value in this, then you definitely should have them. Not doing them because it keeps the bug numbers low, is cheating. You would be lying to yourself.

Also, if you don't fix bugs but keep piling them up, while you at the same time your are "completing" story after story, you are actually reporting a velocity (in stories per week) that is too high. Expectations for the next release cycle will be higher, and it will be even harder to negotiate time for fixing bugs or doing other items.

And more, if your approach results in a similar number of bugs your stakeholders may start asking the question whether your approach is really better than the traditional one.

I'm sure you don't want to let it come to that. So regardless how you look at it: Not fixing bugs and finding ways for avoiding them in the future doesn't help at all. Instead it can be the start of a vicious cycle. And by keeping the number of bugs low, the question of how to deal with bugs becomes a no-brainer!

Tools

No engineer can exist without tools. Tools come in many shapes and sizes. This is no different for software engineers. And there are tools for agile project leaders as well.

For a software engineer most tools are pretty obvious. For instance a compiler, an editor, or a test framework (e.g. csUnit, JUnit, etc.), etc. But then there are other tools that are less obvious. What about the index card that you use for writing your story? What about the cards you use for planning poker (TM)? They are all tools in a wider sense.

An agile project leader has tools as well. Again some are more obvious like a reporting tool that gives him/her the latest financials for his/her projects. But there are others such as if you detect that a group of people is not on the same page in terms of information sharing. Then your tool of choice might be to get these people into one room and get them talking. Communication and collaboration are agile principles and so getting people to do both of this is a tool that an agile project leader has at his/her disposal.

It is important to use a broader definition of the term "tools". If you do you will discover many more tools you are using. Experiment with them. Try out new ones. Drop the ones that don't work for you. Listen to your team members. Often they have the best ideas anyways. Don't put tools away completely that didn't work at some stage as maybe at a later stage their time might actually have come.

Equally important is to look for tools that are simple and easy to use. Keep them as simple as you can get them. No need for an elaborate version control system if you can get away with a simple one like CVS or Subversion which have essentially little more features beyond update, commit, label, or branch.

Simple and small tools are much more flexible. They are easier to learn. They are easier to integrate with your existing environment. They tend to be easier to operate. And you can combine them forming more powerful solutions. If you select a good set of light weight yet efficient tools you can almost use them like Lego (tm) blocks to build the environment you need. And still you stay flexible and can adapt as needed by recombining or reconfiguring your toolset.

An Example

As an example for a simple yet efficient tool let's look at how you evaluate the engineers on your team. Many options exist. In large companies I have found systems (probably running on expensive hardware) which the managers are supposed to use for their evaluations. But there are simpler options. First of all, are you as the manager in the best (or only?) position to evaluate your team? What if you would delegate that task to your team and perform a peer review? What if you could use a simple tool to do that, e.g. a spread sheet that you send to all your engineers to evaluate each other?

You can find such a tool for free here. And here are a few things you can try out:

• Before you send out the actual sheet ask you team to review the categories or the descriptions of them.
• Try out different cycles, e.g. once a year, at the end of each project, every three months, etc.
• Try to expand it to non-engineering roles
• Ask people to also fill in the column with their own name. Is there a big difference between their self-perception and how they are seen by the team?

I'm sure you can find more factors to play with. Let me know how it goes and whether you find this type of tool useful. And always remember:

"A fool with a tool is still a fool." (anonymous)

So always THINK before you start using a tool.

And finally: The agile community would love to hear about your experiences. So I'd like to invite you to participate in the tools stage at the Agile 2008 conference.

To Pair or Not To Pair

Although I have been using pair programming as a standard practice with my teams since 2001 once in a while I still run into the question - usually asked by an uninformed outsider - whether pairing really makes any sense. The naive view is that it appears that two people are doing the work of one so it doubles the cost for most of the items.

Initially I was extremely adament about pair programming. It's called EXTREME programming after all! Quite some time ago I changed my position slightly. Today, when I start working with a team I make it clear that the default for doing any software engineering related work is to pair with a second person.

Does this mean that the people in the team I work with pair all the time? No, not according to my observations. There are quite a few occasions when people work by themselves.

One such case is if people would like to explore a new technology or tool. Different people prefer different learning styles. And before they present their findings to the team for further discussions most people want to understand enough about a topic before using their colleagues time. This gathering of information could be just surfing the web or reading a book on the subject. But it could equally be running a few experiments on a development workstation.

Then there are the usual other activities that most people prefer to do alone, e.g. email, filling in time sheets (yes, there are still a lot of companies who have them), etc. Also, you might want to call your doctor or spouse or log in to your broker without a colleague sitting next to you.

Unfortunately there seems to be only few studies out there on the subject. Laurie Williams' work is available in different versions, e.g. here and here, and also as a book. But some people would like to see additional researchers/authors who come to similar conclusions. Some studies have been conducted in an academic environment, e.g. with students. These studies are easily challenged when you try to use them in an industrial context. (Please note that I'm not saying these studies are useless.)

More generally I believe that reasoning about pair programming using a linear approach doesn't help. System thinking should be employed. Pairing (or not pairing) affects too many other factors. A simple linear cause-effect thinking tends to exclude critical factors.

Based on my observations and experience I would describe pair programming as an activity that has a positive impact on quality, team learning, soft skills, communication, productivity, innovation, creativity, collaboration, training, and many more. To pick one, let's look at productivity.

While many people believe that productivity goes done (two doing the work of one?), I believe that productivity actually goes up (or at least stays the same). My reasoning for that is - again - manyfold.

First of all, some people confuse body time with brain time. Have you ever walked through a development department where people work solo? Run a little experiment. Peek at the screens of the people and take a note of the percentage of people not currently looking at your IDE (or other work related tool). Now, do the same experiment with a team that uses pair programming as a standard practice. Or even better work with a partner and try to track your stock quotes at the same time... I think, you my point. With pairing there is no way to back out or to just doze off. You're in it full time. The ratio of brain time versus body time is much higher than with solo programming.

Next, a pair can and will be much more adament about the quality of the change set they deliver if they are members of a properly trained agile team. They will merciless refactor trying to use the simplest possible design and implementation to get the job done. They will be creative and innovative in doing so. They will have automated tests in place preventing other people from accidentally breaking their code. And once they have committed their change set they usually can focus entirely on the next task without having to go back to some past work.

There are other factors that are worth exploring, but I'll save them for now. I'd like to come back to them in a future post in this blog. As always, I would be very interested in hearing about your experiences and also about your feedback to this post. Thank you!