Xp Doesnt Cover That

There are a lot of problems with the software industry, and a good number of them are not actually technical. What if the marketing department decides we should implement a feature that nobody wants? What if the usability folks decide to add confusing, non-standard features - or, in the more common case, what if there are no usability folks?

There are many problem domains that are only peripherally related to engineering concerns: Marketing, usability, look-and-feel design, information architecture, etc., etc. They are all important. But XpDoesntCoverThat.

ExtremeProgramming, to my mind, does not aim for complete and total software satisfaction. It's aim is much more modest than that. It says: We can deliver what our customer asks for with minimal risk and maximal quality. But if the customer has no idea what to ask for, or asks for stupid ridiculous features, ExtremeProgramming doesn't aim to fix that. If the customer asks you to implement a financial web site that orders transactions by how many dogs the recipient owns, ExtremeProgramming does not help you tell the customer "Uh, maybe that's not the most useful feature."

In my ideal ExtremeProgramming workspace, I imagine all this kind of stuff - prioritization of goals, communication of client involvement - abstracted behind the mythical Client figure. In practice, I suppose that person is often called a ProjectManager.

But if the customer has no idea what to ask for, or asks for stupid ridiculous features, ExtremeProgramming doesn't aim to fix that...

Are you sure? Maybe the fix is not a direct fix, but doesn't the presentation of requirements by users as stories push the process toward exploration in such a way as to optimize the results, even when nobody knows at the outset where they are truly headed?

There must be things XP doesn't cover, but this particular aspect of requirements doesn't seem to be one of them.

Hm. That's very true. And one extremely positive requirements-related step is by avoiding massive spec-docs and asking for specific, small UserStories, you get a need for clarity. You can hide obscurity in a 40-page spec doc (because nobody reads the thing anyway), but you need to be ShortAndToThePoint if your requirement is written on an index card. And that clarity drives the "exploration process" you mention ...

I guess what I'm thinking of, though, is requirements that depend on significant up-front, non-software-engineering analysis. For example, let's say the client comes to me with a requirement that relates to the organizational scheme of a corporate intranet with an eventual 10,000 pages. It's within the aegis of ExtremeProgramming for me to say "I can do that in this amount of time", or "Your requirement is vague; can you please clarify it so I can quantify the risk and time needed for technical implication."

What ExtremeProgramming does not discuss is how I might say "Your categories are awful, and if we implement them in this way nobody's going to use your intranet." In practice, of course, the software engineer should never have to say such a thing. But these kinds of things are always neglected, and programmers tend to notice them, if for no other reason then the fact that they spend so much time with the product. So they look for ways to say it, and some of them seem to look to ExtremeProgramming.

I like this 'feature' of XP. It cleanly separates responsibilities. If the customer makes dumb decisions about what they want, it's the customer's responsibility, and everybody, including the customer, knows who was responsible for the bad decisions. This is in contrast to the more familiar Chaos model, where developers get blamed for things that are not their fault, but because of ambiguity, they are easy scapegoats. Ridiculous schedules come to mind as an example.

"Your categories are awful, and if we implement them in this way nobody's going to use your intranet..."

It's to XP's credit that it offers you no platform to make such a statement, if indeed it doesn't. For one thing, such a judgment embodies an assumption that you know the problem domain and the users better than your customer. How many times have you been wrong when making such judgments at this stage? On the other hand, thinking story-wise, what is to prevent you from asking questions about how the categories work and for whom they are most optimal? (In doing that, you would be soliciting a story.) It may still be that XP does not address this technique directly, but the story-mindedness of the approach pushes you in that direction, if you listen to it.

I didn't start this page as a criticism of ExtremeProgramming, but more as a discussion of what parts of the process it covers and does not cover. It's a point worth addressing, based on many discussions with programmers who believe it to be a deficiency of ExtremeProgramming, when it is actually an intentional limiting of scope.

That said, I think it's still easy to see poorly thought-out decisions be made by the client. To take the example of web sites, it's quite common to be a programmer who has given more thought to the general issues of usability & information-engineering than your client, perhaps because programmers use the web a lot? This sort of criticism is not an expert opinion, but what often happens in the real world is not that a usability expert has considered the problem and their opinion differs from that of an engineer. What is far more likely is that the harried product manager has been given no time and no resources to think about usability at all, and the resulting product will be obviously unusable. This opinion is often easy to come to, not as a usability expert, but as somebody who will be working intimately with the product for the following weeks or months.

But again, XpDoesntCoverThat, and this is undoubtedly a strength. (Something should cover it, though.)

I think it does cover it as well as anything might be expected to. A process of iteration based on stories based on real experience leads somewhere. What is your process for arriving at usability and how does it differ?

ExtremeProgramming is a technically oriented methodology, and technical aspects are not the only relevant aspects in the success of a software product. Perhaps they're not even the most important. It's not enough for a product to be (relatively) bug-free; it must also be useful, and usable, and these concerns are important -- but they are also outside of the domain of ExtremeProgramming.

In my mythical web development company, I'd imagine a full-fledged usability team - many of whom would probably not know how to code a single line of Java - conducting lots of user tests. I'd start with JakobNielsen's recommendations (http://www.useit.com/alertbox/20000319.html): Short bursts of five-user usability studies, conducted maybe two months apart to help advise the client on what to ask the engineering staff to do.

This approach is not at all opposed to ExtremeProgramming. It would share many values with ExtremeProgramming, such as iterative design. And a commitment to ExtremeProgramming would help a company spend some energy on usability, by minimizing the amount of time required to worry about engineering. So the two are certainly compatible.

But they are not the same. ExtremeProgramming deals with programming. User tests are not programming. XpDoesntCoverThat.

I think your assessment is accurate. This is clearly an area that XP does not cover directly, and any indirect coverage would be due to a customer decision unrelated to any of the XP practices (i.e. "This doesn't work the way I was hoping, let's change it."). Failure to make that decision rests solely with the customer, and no XP practice will be able to fix an obstinate or ignorant customer.

True enough. However, equally true: no XP practice will be able to fix an obstinate or ignorant programmer.

When the client doesn't know what technology to ask for, that isn't always due to their being ignorant or obstinate. Often, it's because technology is really complicated, and it's hard to decide what to ask for. This is, in theory, what usability experts, strategy consultants, operational consultants, etc., are for. (I've had hardly any direct experience with these sorts of folks, so I can't say whether they live up to their promises.)

My basic response to XpDoesntCoverThat is "So what? No, XP doesn't cover every possible situation. Suggest an improved way of handling situations, but don't just complain."