|
Extreme design versus extreme programming
I've just returned from the What's Next conference in Brattleboro, Vermont, where I gave a pair of talks (one on web services, one on application servers). The keynote speaker for the day was Alan Cooper, designer of Visual Basic, author of several books, and founder of a company that specializes in interaction design.
Cooper's view is that the kinds of disasters that have always plagued the industry -- most recently, the catastrophic outcomes of many CRM (customer relationship management) systems -- are a result neither of poor strategy, nor of poor engineering, but of a failure to properly coordinate the two. The missing piece in his view is product planning and design, done according to a methodology that Cooper has devised and that his company practices. This methodology aligns itself with Colonel John Boyd's OODA (Observe, Orient, Decide, Act) loop, fashionable in military circles.
Central to Cooper's methodology is the documentation and analysis of personas. These are carefully thought out representations of key actors (Lucy the sales rep, Bill the investor) that aim to capture the goals and motivation of these actors. From these you deduce what tasks they perform according to what priorities, then derive the requirements for interactive software behavior.
Where Cooper departs radically from some now-fashionable practices -- release early and often, extreme programming -- is in his insistence that designs can and must be worked out in essentially complete form on paper, on whiteboards, and in the brains of the designers, over a long period of thoughtful iterative refinement, and then delivered as a complete description of the personas, their goals and tasks, and the required software behavior. In other words, a specification. But, he argues, it's not a rigid old-fashioned specification driven by features and functions, which (I admit) all too often results in products that solve the wrong problem. Instead, it's a flexible new-age specification that's correct (he argues) because it accounts for goals and solves the right problem.
Although I am a release-early-and-often kind of guy, I do not discount Cooper's approach. But here's where it gets weird. My own experience -- admittedly on smaller systems, not CRM-class battleships -- tells me that releasing early and often gets people interacting with software, and finding unanticipated flaws (and benefits) that guide subsequent iterations. Cooper flat out denies that this approach can have any value whatsoever.
Here was my question: "Is there no hope that interaction design can itself be made interactive, with the assistance of software?"
He doesn't rule out the possibility, but thinks that useful interactive prototypes are unlikely and, in any case, unnecessary. In his view, interaction designers (like him) are born, not made, in the same way that programmers are born, not made. Both have special and uniquely human abilities to visualize and sequence complex and abstract systems.
Fair enough. But there's something bizarre in all this. Let's take eBay as an example of a successful software system. How much of the current behavior of eBay was anticipated by its interaction designers, and was present in the first release of the system? And how much has accreted over the lifetime of that system, as its users and developers have collaboratively evolved it?
I don't deny the value of doing the best up-front analysis, user modeling, and design that you possibly can. Cooper's methodology and ideology, though, seem to deny that there is value in deploying your best first effort and then refining the design based on real use as opposed to mental simulation of use.
It's extreme design versus extreme programming. I don't buy either one completely. Call me an extreme anti-extremist. Call me a bundle of contradictions. There's more than one way to do it. I'll never sign up for a methodology, no matter whose. But I'll learn what I can from all of them.
Here's the best take-away from the talk. Now that we have largely replaced human touchpoints (sales clerks, travel agents, etc.) with software, it is the behavior of software, not human employees, that projects the corporate brand. So every business is now in the software business, and the quality of the software's behavior is a crucial success factor. Amen to that. However we get there, high-quality software behavior is a goal on which we can all agree.
Footnote: Look at what Google came up with for the title of this item. Eerie. I'm going to have to start searching on the titles before I write the items.
10:09:43 PM 
|
