Slashdot Mirror
Extreme Programming vs. Interactive Design
Hoff writes: "Here is an interesting interview with Beck and Cooper pitting extreme programming vs. interactive design. Personally, I'm all about extreme programming. It's a novel approach to help get the management work with, and for, the software engineers."
Well, some real experience here. We've designed and built many frameworks in our company. I'll take a smaller set of four frameworks when we were learning XP. The two that were done with XP turned out wonderful and haven't failed us for a year and a half now, continueing to get more and more powerful as time goes by. The two that were designed down to the minutest details turned out to be horrible systems. We want to trash them and get rid of them - but of course, that's hard to do now that they exist. They don't 'evolve'.. they just sit there stagnant and smelly like.
When I was reading the article, I couldn't help but think of a project I headed up for a little over a year. It was a small project (6 month) that an technologically ignorant sales person headed up the initial interaction design document. He spent time with the customer detailing the specifications as much as he knew how. But still the requirements were very vague, and I needed constant phone calls to finish the project.
What hit me was this: the client was not able to actually specify what they wanted. They would ask for a vague section of the project, then I'd ask detailed questions pertaining to the interaction and behavior. And they would give me direct and specific answers that were in direct contrast to what they wanted when they saw it. They would see what they had asked for, and realize then that it's not really what they wanted. In this case, there really was no way to find out what they wanted (*really* wanted, not just what they wanted this week) other than showing them a demo. If I could script a simple mock of every feature and demo it to them immediately after they requested it, it would have saved me a whole lot of time. As it was, the project looks nothing like the original specification (not just more detail, but fundamental changes to the behavior and requirements) and it's just a mess (and still not done, after more than a year).
Cooper (really badly paraphrased) places more emphasis on pre-coding work. But it seemed to me that there are situations where a client lacks the ability not just to communicate what they want, but to envision a system and even know what they need. If a customer is unable to sufficiently help you in pre-coding work, then it's on code and actual demo that will enable them to *realize* what they need, and give feedback.
It has a very good analogy to my parents building their house. They wanted an island in the kitchen that was a little oversized. After it was realized, they found that there wasn't enough room for cabinets in back of the island. They knew they wanted a bigger island, but did not know the implications of what they wanted and the end results. If they had a virtual tour, or even a few feet of plywood, they could have seen that they really didn't want that. They lacked the knowledge or experience to specify what they really wanted.
I believe with a company that's on top of it's own business process and that has a good handle on the behaviour they're trying to automate will work well with Cooper's methods. Having a detailed requirements document makes work so much easier. But with some customers, there is *no way* to have a perfect plan before code is layed. So having a little code layed out and getting feedback early is the next best thing. What do you guys think? (Esp what other experiences have you had with the two methods?)
Actually, clients do call up and say things like that, no matter what business you're in. I spent several years working as a mechanical engineer before switching to software, and clients never stopped asking me to change things that there was obviously no hope of changing so far into the project.
The problem with software is that it is perceived as being easier to change than it really is, even by people who develop it, and certainly by people who manage developers. So when they ask for the moat, we actually have to build it.