Extreme Programming vs. Interaction Design
When two development design visionaries meet, there's room for consensusbut not much.
by Elden Nelson
Posted January 15, 2002
Kent Beck is known as the father of "extreme programming," a process created to help developers design and build software that effectively meets user expectations. Alan Cooper is the prime proponent of interaction design, a process with similar goals but different methodology. We brought these two visionaries together to compare philosophies, looking for points of consensusand points of irreconcilable difference.
The Starting Line
Let's root this conversation in real life. You've got an important development contract, but in the past, the customer has just given you a one-line description of his high-level concept, and that's about as specific as he's been. What do you do?
Beck: That was exactly the problem one of my clients faced last week. We had product managers who wanted to say things like, "force this product to OS-390." Then, three months later, they wanted to come back and have the results. So they're getting answers like, "Oh, it's going to take us three more months."
You could try and do a better job on the engineering side of getting the details of exactly what they meant by this and spending more and more time on estimation, requirements, specifications, engineering methodology, computer-aided yadda yadda yadda forever … and never reach anything like a satisfactory conclusion. Or you can say, "Customer, your job in this process has to be more than just giving us the bullet item; you're going to have to take a half step toward engineering, and engineering is going to take a half step toward you." You take that one bullet item and turn it into twelve things you care about and would recognize as signs of progress along the road toward delivering this product on OS-390.
If you click off one of those every week, after two weeks, you're going to have a pretty good idea whether you're going to get what you want at the end of three months. After four weeks, you're going to be absolutely certain whether you're going to get what you originally wanted at the end of four months.
It does mean that the specification of functionality on the business side has to break down one more level. And to make it as powerful as possible, it has to also come with a lot of activities that used to be thought of as post-hoc testing, where you'd say, "We want the system to do this, and that meanshere's a little script by which I mean is really something automated, and that script will run when and only when the one-twelfth of our whole system has been added."
Back to top