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."
I'm not sure how much mainstream acceptance is possible for any paradigm that incorporates a faddish name like 'extreme'
I'd much rather see our profession associated with more difficult disciplines, like maybe engineering, than with mountain dew commercials. Ever hear of The Extreme Scientific Method? How about Extreme Structural Engineering?
Interviewer: so, what are your goals?
Me: Dude, I want to be like, the most X-Treme programmer!
Of course I've said nothing about the actual process. The article contains a link to a list of practices which include:
Continuous integration of changes
Customer on site
These two things give me nightmares remembering customers who have had cute ideas at the last minute. Other than that is looks like the waterfall model. My humble recommendation is that it needs a good name change.
Perhaps they woudln't have modded you down if you didn't make the same idiotic joke that someone else always makes when someone says "Extreme Programming"
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?)
What is it about the these XP advocates, are they really that poorly read that they genuinuely think they invented these ideas ?
XP is NOT the awesome paradigm shift that it is made out to be by its advocates; it is NOT even that new. It's just a repackaging of the failed RAD fad. Now XPer's can make the same mistakes all over again, produce poorly specified, unmaintainable mess. XP is an exercise in self promotion and marketing hype.
Those that have not come across it (or the ideas) before should read more REAL Software Engineering texts.
http://whatis.techtarget.com/definition/0,,sid9
I really have to wonder how much connection to the realities of programming in a commercial environment the average Slashdot editor/admin has, and if they're really qualified to comment on the relative merit of competing development methodologies...
my sig's at the bottom of the page.
Contrast Cooper:
How many complex systems has Cooper constructed?
But here's the exchange that really drives it home:
Cooper: Building software isn't like slapping a shack together; it's more like building a 50-story office building or a giant dam.
Beck: I think it's nothing like those. If you build a skyscraper 50 stories high, you can't decide at that point, oh, we need another 50 stories and go jack it all up and put in a bigger foundation.
Cooper: That's precisely my point.
Beck: But in the software world, that's daily business.
Cooper: That's pissing money away and leaving scar tissue.
Zing! Cooper might be right about pissing money, but it's what happens all the time, and Beck and XP have given us tools to deal with it.
In the article, someone--am not sure who, I read it last night, slept since--mentioned that building software for a client is like building a building for a client.
How would the architect like it if the client kept calling and saying things like that:
--I've decided to add a moat.
--Can we build in in France for the same cost?
--I've decided to add 30 stories... How long will that take?
--Each office suite must have a view of the Ocean.
--I don't like glass on the outside, let's go with granite.
--I don't like granite for the outside, let's go with marble.
--I don't like marble for the outside, let's go back to glass.
--Why are you charging me so much?
--Why is the design of the project taking so long?
Bang Bang Bang...
My point is:
I don't write a single line of code until the client has told me, specifically, what he wants the program to do.
If the client is unable to formulate that in the form a concise and well-written spec, then I write the spec for them (in English, not pseudocode), and I bill them for that.
If they don't know what they want to software to do to begin with, I do an analysis of their business process, with flowcharts, goals, SWAT and all. Then I write the proposal for the software to streamline their operation and allow them to leverage their competitive advantages. And I bill them for that.
I tell them up front that that is what I'm going to do. If they don't like it or they don't want to pay for it, I say: Call me back when you do.
By the way: it really helps to have taken upper division business courses, and have a healthy (not biased) dose of knowledge about the current business world (Wall Street Journal or the like).
That way, when your client balks at the cost, time, and effort involved, you say: Are you willing to lose any market share to (insert their competitor's name)?
Anyway. Writing software is not really about coding, it's about what you can do to make businesses more productive and competitive. If you can do that, it doesn't matter if you use COBOL or C++ or C# or Java or what.
Extreme Programming (the name's gotta go) and Interaction Design both use different methods to address the lack of proper business analysis and requirements.
"Piter, too, is dead."
... learning about things before criticising them ? I agree about the name, but XP's primary purpose (as Cooper points out in that interview) is to accept the fact users initially have no clue what they want, and work with it. If the customers see every iteration of the system, and the system is released every week or so with at least one new, small, useful feature, they become much better at describing what they want to change, and much less prone to last minute "bright ideas".
The rest of XP is mostly there to make constant change possible without producing an engineering disaster. Since most projects exist in a state of constant change anyway, this seems better than the usual approach: to become inflexible and dogmatic in the face of the customer's unreasonable stupidity.
Most coding is easy. Thats exactly where XP is coming from. Most people have the instinctive hatred of rewriting stuff, but given that coding is easy, there is no good reason for this. You can see it in what Cooper says: comparing coding to pouring cement. XP involves rewriting lots of code, so Cooper reckons its like demolishing bits of building and rebuiling them.
According to XP, he's wrong, and there are reasons to believe it is right. Rewriting code is not nearly as expensive as building and rebuilding walls, and by writing and then rewriting something, you gain a better knowledge both of the customer, and of the problem.
What Cooper seems to be called "Interaction Design", sounds like what most people call "Analysis": figuring out what the system must do, how it is to be used, what information it works with, and so on. I'm not sure why Cooper has invented a new word. Possibly self-publicity, possibly that there's a school of voodoo analysis that involves people who write a flowchart and a couple of CREATE TABLE statements and then **** off. Either way, its another one for my list of Damning Inditements of Our Industry.
One you realise Cooper is really talking about analysis, the conflict with XP becomes much clearer. The biggest issue I have with XP is that they don't do analysis: they don't find out anything about the customer's domain before trying to start work. Admittedly they will find out as they go along, but it does seem effort is being wasted in there.
and that would make the moderations redundant, not offtopic and troll. and what the hell makes this worthy of an insightfuL? its an ac making some stupid OT comment.
I think the moderation of all the posts critical of XP to 'flamebait' is a perfect illustration that it is all style over substance, and stand on its own merit.
This post perfectly illustrates the danger of making out of context quotes and not understanding the issue(s) involved. It seeks to suggest that Cooper loses because he cannot live with development [in the real world].
...
I would suggest this is poor advocacy at best and deceitful at worst.
Coopers comments below:
Cooper: I think XP has some really deep, deep tacit assumptions going on, and I think the deepest tacit assumption is that we have a significant organisational problem, but we can't fix the organisation.
This perfectly illustrate this issue, Coopers solution is to fix the root cause [poor project planning/management] and not the problem [imprecise requirements/impossible deadlines]. Kents solution (XP) is to paper over the cracks and try to live with these requirements, and quit before your 'fail'. It seems XP boils down to the old adage of fixing the symptom and not the cause. This approach only produces an adequate solution at best and never results in excellence. MHO is that excellence should be the target of any Software Engineer who regards himself as a professional.
[rant]
Quite how this deserves +5 informative is mystery to me, it appears to me that the moderators did not even check this against the linked article, and moderated based on their own beliefs on XP rather than the merit of the post.
[/rant]
In most of the places I have worked at business process resides in a person, usually a manager. If you need to refer to a process you refer to what Mr./Ms. X is or is not doing. And then Mr./Ms. X leaves and the next person has to reinvent the wheel, again. This is the situation that most software developers find themselves trying to automate. At the one company that I worked for that was 9001 compliant, documenting the business process was a very peripheral activity.
The vast majority of businesses are in serious disarray. I believe that if business processes [behavior] were captured in something like UML and reflected on, it would result in an extraordinarily efficient business.
How many business are going to jump up and begin doing this? Well, OOAD often outputs a Use Case for the business process that is being automated. All it would take is for a business to have the will to put those artifacts to another use and to keep them up to date. At some point an organization will hit critical mass. Most people will know what the UML diagrams represent and how to use them. That way, when someone needs to talk about a process, they don't have to talk about Mr./Ms. X.
So, where am I going with this. XP makes the business people be more responsible for describing [and understanding] their process and the deliverable that they receive. It also gives the customer a very good insight into the amount and type of work that goes into developing a software product. Interaction design, on the other hand, takes that responsibility away from the customer/business person and insulates them from the development team. It looked to me from the article that the interaction design people don't just create a requirements doc but reengineer business process as well. This might be appropriate at times, and sounds like interesting and enjoyable work. But - from a larger perspective, I think interaction design is trying to solve the wrong problem. It seems to me that interaction design might be better applied to the ongoing issue of business behavior and process documentation, a meta process perhaps, than as an intermediary in the software development process.
Once the business process documentation and staff understanding was in place XP would provide the continuous process automation improvement to keep process and automation in sync for as long as needed.
Once the business process documentation and staff understanding was in place... yeah, well XP works now too;-).