Problems of Software Development 3

One interesting thing I've noticed about Extreme Programming in particular is that any objection you can present to a single practice, usually can be responded to by pointing at one of the other practices.

"We don't have the manpower to test the whole project every two weeks!"

Ah, but you've been writing unit tests all along, right? If your application has a solid set of unit tests, and every one of them pass, then you have a pretty good feeling that even if the new functionality you've added isn't quite right, you've probably not made anything worse for the existing customers. Besides, on big, complicated applications there's usually a process for getting new, isolated fixes out the door long before the next release comes out six months or a year down the road. What these fixes come down to are sort of a "Frequent Iterations" emergency measure - that is, the company doesn't believe in releasing software very often, but the customers insist upon it, so out the door it goes, sometimes whether it's been adequately tested or not.

Finally, automated acceptance tests are a key feature here as well. Unit tests are great, but they work at a deep level of the application. When it comes down to it, the user is going to need to click some buttons and type in some data, and is going to get an expected result. But there's no reason for a person to be doing work that computer is able to do, even if the computer has to move its own mouse and type on its own keyboard.

"Our users are going to file hundreds of change requests! The developers will be buried!"

But you've got a Customer, right?

I think the word Customer in the Extreme Programming sense is really poorly named. Everywhere you read about someone attempting this practice, they say, "Oh, but we don't do that. We have shrink-wrapped software." Or, "We have a dozen customers." This misses the point. Customer, as defined in the XP sense, is required to be a single person, or at the very least a committee. Whether the person speaks for one, a dozen, or 100 million actual customers is beside the point. The customer is responsible for looking at all the change requests, putting them into a neat order, and getting them to the programmers, who will be able to estimate a date based on the highest priority items.

"How will we ever know when it's done if we don't have the requirements set in stone up front?"

But what requirements were set in stone? Generally, they involve three factors; the project's:

• Time allotted
• Budget
• Scope

It neglects the simple fact that a project actually consists of four factors: the three above, plus quality. However, only three of these factors are independent; the fourth one will depend on the others. So, if you specify a project's Time, Scope, and Cost, you have fundamentally specified its Quality as well, and the only way to raise the quality is to lengthen the time, increase the cost, or reduce the scope.

So how do you know when the project is done. I'll look at that next.