|I think it’s a combination of technical and social factors that leads to all the defects in deployed software. Part of it is the attitude that software is just inherently unreliable, and customers are conditioned to accept that. Developers are conditioned to accept that. Testers are conditioned to accept that. We just decided it was like the weather and there’s nothing we could do about it, which isn’t a very responsible position because in fact, there’s a lot that software developers can do about it.
Kent Beck, as quoted in Extreme Programming inventor talks about agile development
Kent Beck gave a great interview that’s posted on the IBM developerWorks site, where he talks about the payroll project at Chrysler. It’s a great read.
Now, the payroll program would handle Chrysler’s entire payroll, representing 1/10 of 1 percent of the entire US gross national product — at that scale, with union rules and all the places they operate, it’s a complicated program. They had a crying business need; it had to work. At the same time, this wasn’t rocket science — we just had to execute.
So, after a couple of weeks I interviewed everyone one-on-one. I told the first guy that we’ll divide the project into three-week intervals called, say, iterations. In each iteration we’ll implement a few new features called stories. We’ll write down all the stories we need, slot them into the iterations, then do it.
I told the next guy [I interviewed] that we have these three-week iterations divided into stories. For each story we’ll write these, um, acceptance tests to demonstrate that the stories meet the customer’s expectations.
With each person I interviewed I added a little more. By the end of the day, I’d interviewed 20 people and had laid out Extreme Programming’s basics.
My favorite quote from the article? “Sucks less isn’t progress.”