I've been reading about extreme programming (XP) quality lately. First off, for people not familiar or a little familiar with XP, it may seem like an ad hoc process. How can quality be important in an ad hoc process? That question is made from a false assumption: quality is actually often more important in XP than traditional software development. XP is not ad hoc, it's lightweight.

Quality comes from a few different places in XP:

1. pair programming (peer review as you write the code, not later)
2. test driven development (developers write tests and code)
3. green status for code in the repository (100% unit tests pass always)
4. using the simplest thing to get the job done (less to test)
5. customers writing acceptance tests, ensuring they get what they want
6. releasing often to solicit feedback

The reality is that most of us are not going to be building NASA rocket engines or airplane flight control systems. These types of systems demand a level of quality and peer review that XP cannot possibly deliver (that's just my personal opinion). Waterfall and processes like the CMM have a place in constructing these systems. Our friends over at Motorolla India have it down pat. Personally, I have no interest in engineering these systems.

Unfortunately for the rest of the software development world these heavyweight processes are not agile. They cannot respond rapidly to changing market conditions or bugs found in the platform or other factors. They also take a long time to produce a working product that users can poke at because all of the design work has to be done up front in people's brains and on paper. If they deliver something that the customer doesn't want, the developers won't find that out until the customer has the cell phone in their hands saying "this sucks!" They can put the feedback on that product into the next model, but the damage is done. That kind of investment in code is risky.

So the first step we as software engineers have to do involves two admissions:

1. All software contains defects
2. We don't have to fix all of the defects right away

This may seem pretty bizarre, coming from a profession that wants to be known as "engineering" but the truth is this: the defects that we can ignore have little to no impact on the system. We will fix them in a priority that suits the customer, mixed with new features. As well, bugs or defects are usually just deviations from the requirements. If your requirements are wrong in the old process, you have to go back up the waterfall and fix them. In XP you just make a new user story, change the acceptance tests, fix it and move on.

You should know though, that this is just my personal opinion. The XP literature rarely admits that unimportant bugs can be sitting in the code for a long period of time but I think it's an obvious assumption given the XP process: if the customer never tells you to fix a bug, it will never get fixed. My theory is that the XP guys don't like to admit that maybe the process has flaws like implicitly allowing bugs. Of course it does: the flaws are the people, the engineers building the system. We make mistakes all the time, and the process we use has to be able to manage these mistakes in a graceful way. Changing a bunch of artifacts up the waterfall is painful and takes time -- waterfall doesn't account for mistakes made by humans, it punishes them. At every step you have to be perfect and know exactly what the customer wants. Iteration is a lot less painful.

In the agile world, if a bug is important enough the customer can vote to get rid of it in as quickly as one iteration (usually two weeks). Ultimately quality is up to the customer in an agile process, so it's their call -- but don't worry, they won't let the quality get too bad. Remember that the customer has a stake in great quality too. The ability for the customer to make the call about quality is what makes agility so great.

Let's not forget about new features -- they go in on demand every two weeks as well. The customer gets her most important features sooner, reducing the risk that the implementation may not solve the business problem at hand. The feedback from that feeds right into the next iteration. There isn't much connection to the past, just to the present: not oh great, the current code doesn't match design document X or interation diagram Y, we have to go back and fix it just let's change the code and tests to work like the customer wants it NOW. There are no artifacts to go back and change. Remind me to talk about artifacts in XP some time.

Bugs are a funny thing in XP. Because of the high code turnover rate, a bug you may know about that has been in the system for a few months may be nuked by a refactoring for a new feature at any time. You never know what the customer is going to request next, you are not a mind reader, so don't even try. Why would you spend the time to fix a bug that will just be nuked? If the bug never effects the customer in a big way, or a workaround is managable, then everything is cool for them. They may not want to have to pay to fix it if it doesn't impact them that much.

If the code for that area is relatively stable and the customer thinks the defect is important enough, sure you can write a user story to fix it and if the customer thinks its important enough she'll prioritize it so you can go in and fix it. The customer rules in XP.

So a few conclusions: the software most of us write does not have to space ship quality. Just hold yourself down and get yourself to admit that we aren't sending people to the moon. Defects are prevented in XP by additional testing not found in regular software development BUT the iterations and process ensures that when found a defect can be fixed quickly. Responsiveness is more important! And finally: in XP the customers have more control. As a customer, wouldn't you like to have more control over your where your money goes and what the software does? Yeah, I thought you would.

Disclaimer: this is my understanding of XP and I don't speak for the official XP guys. If there are mistakes in this blog post, please correct me in my comments. Thanks!