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."

Comments

Re:What's in a name?

[valkadesh]

I'm not sure how much mainstream acceptance is possible for any paradigm that incorporates a faddish name like 'extreme'

There are signs that the name will change from 'Extreme' to 'Agile'. This for two reasons:
1) It's easier to sell to the management an 'agile' development process than an 'extreme' one.
2) There are plans for melding the many agile development techniques in just one discipline.

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.

Each and every model looks like waterfall. The difference between the various models is the amount of feedbask between phases that the models allow (I'm simplifying, of course). Extreme Programming takes the feedback to the limit, by use of methods like continuous integration, on site customer, minumum bureaucracy. The goal here is to give the customer something valuable ASAP.

Re:Not new

[Twylite]

Have you even looked at extremeprogramming.org?

XP is divided into four major areas of activity: Planning, Designing, Coding, Testing. The project starts with requirements analysis and an architecture or framework for the entire system. Emphasis is placed on simplicity and preventing feature creep. Then it goes into an iterative development phase in which the emphasis is on rigerous unit testing and feedback, ensuring that code works, and problems are detected early.

The value proposition of XP is risk control: feedback provides a good idea of problem areas and allows for handling them when they arise, and iterative development ensures that feature creep and miscommunicated requirements cause limited damage.

You are correct that XP is not that new. It bears many similarities to the Rational Unified Process, but is in no way related to RAD. XP stresses the importance of an underlying architecture and extensible design, before coding is started.

Would you care to expand on what you mean by "REAL Software Engineering texts"? Most people seem to believe that scientifically provable methodoligies are the only option for software engineering ... how unfortunately that it was recently proved that it is impossible to reliably estimate software complexity, which is a core requirement for software engineering.

Or perhaps you have forgotten that software engineering, not other engineering disciplines, does not concern itself solely with technical aspects of the software, but business aspects as well: resources, deliverables and schedules.

XP is significant in being one of the least presumption of design methodologies. It does not require any knowledge, on the part of the programmer, of the business processes of the end user. Many software engineers think this is wrong, without realising that business process engineering is a sector-specific activity and an entire field of study; not something a software developer can pick up in a few weeks in order to do requirements analysis.

Cooper gives an example of a building architect interacting with the customer and the engineer to determine all of the building requirements before building starts. What he fails to take into account is that the building is a framework - as long as it has the right size, foundations and number of floors and elevator shafts, it is going to support a huge variety of functions.

Once the shell is complete, other teams move in to customize bits within the building. You can vary the number of elevators available within the limits; make them faster or slower, or only stop on certain floors. Each floor can be divided up with hardboard walls, plumbing and electricity get installed into ducts, aircon is added, carpetting, and finally furniture and fixtures. These don't need to be designed up front.

XP, unlike non-iterative methodologies, happily delays these details until later. RAD, by comparison, starts with the wall art and curtains, adds some furniture and walls, and then falls flat because it doesn't have a building.

Beck 1, Cooper 0

[sohp]

Kent Beck effectively skewers Cooper in the interview. While Cooper talks in the abstract about business process, requirements elicitation and better design techniques, Beck hits on the realities of everyday software development.

Beck: From the customer's perspective, no. I've had teams be called "whiners" because after 25 percent of the budget is spent, they're saying, "We have 10 features to add and we're going at half the speed that we expected. Which five would you like us to work on first?" And the customer says, "Oh, you whiners. Work some overtime or just get back to work or quit complaining." What do you say in a situation like that? You say, "I quit." Life's too short to work on doomed projects you already know are doomed after 25 percent of the budget is spent.

Contrast Cooper:

I believe that defining the behavior of software-based products and services is incredibly difficult. It has to be done from the point of view of understanding and visualizing the behavior of complex systems, not the construction of complex systems.

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.

Re:Not new

[Martin S.]

Have you even looked at extremeprogramming.org [extremeprogramming.org]?

Yes, browsed site, partly read the book (#1). I have used some common techniques such as paired codering, I've never 'used' XP as such.

(#1) Pretty much the reason I gave up on it was the egotism 'look what I've invented, aint I clever attitude' when none of it is really new, and the constant name dropping. Well I've also worked 'Blue Chip' and produced and design my own processes. However unlike Donavan and Kent, I'm well aware I did not invent the fundamental techniques, something that seems completely lost on them. The expression 'standing on the shoulders of giants' come to mind and they are not the giants they seem to think they are.

XP is divided into four major areas of activity: Planning, Designing, Coding, Testing

I strongly disagree, it pays lip service to Planning, Analysis and Design phases and focus on Iteration, iteration and more iteration of the coding and testing cycle. Indeed that is one of its key flaws, it specifically excludes planning ahead, excludes prototyping (spikes are not prototypes because the code base is included in the final project, they are an early/initial iteration).

You are correct that XP is not that new.

Well that is my main contention conceeded. :)

It bears many similarities to the Rational Unified Process, but is in no way related to RAD.

However I don't see how you can claim it is related to RUP but not RAD. When the most obvious similarity in all three is the shift from a traditional 'waterfall' process model to an iterative process model.

One of the key aspects of RAD was two people around each PC, XP has certainly take this to extremes, they seem to have increased this to 2 Coders and a Domain expert now. A key difference with RUP, is it includes Architecture, Analysis and Design phases which are absent from XP.

XP stresses the importance of an underlying architecture and extensible design, before coding is started.

This is just plain wrong, these claims cannot be justified, indeed this one area where XP is self contraditory, it 'claims' it but also prohibits the process features that make it possible. It specifically excludes any architecture phases and 'rules out' forward planning, and

There are other contraditions, the idea that you don't waste time 'documenting' yet demand's strong adherence to code standards.

does not require any knowledge, on the part of the programmer, of the business processes ...

Just how this is reconciled with this:

stresses customer satisfaction.

I have no idea.

Would you care to expand on what you mean by "REAL Software Engineering texts"?

I mean texts about Software Engineering as a discipline/subject not a Software Engineering texts about a specific methodology. So :
Software Engineering, Somerville.
Software Engineering Practice, Pressman.
Mythical Man Month.
Code Complete.

IMHO, All essential reading for any professional developer. Indeed I always seem to find the biggest advocates of XP have never read any of these. They are all hackers, not Software Engineers. The whole XP thing is a hackers charter, with little to do with Software Engineering, it may be suitable for small scale bespoke systems for single users, but not large scale, high value, multi-user projects.

Most people seem to believe that scientifically provable methodologies are the only option for software engineering ...

Well I don't.

I have a range of both macro (RAD, JSD/JSP, Prince, OOAD, SAD, SSADM, OMT, UML, RUP, ERD, FARP) and micro (CRC,Peer-Review/Codewalking, etc)tools/techniques at my disposal, I use them when relevant and use some constantly (ERD, UML, Peer-Review) some only slightly (i.e. FARP, Prince).

If you are advocating XP over other methodologies, how many other Systems Development Methodogies have you used ? Just to provide a a point of reference !

Re:Some clients can't handle interaction design

[Anonymous Coward]

Spend some time on paper with a client. Starting from scratch with an interface and drawing it on paper - saying that when you click here it should go to this screen. Tell them that it will take a day or two.

Programming an interface is hard work. Don't bother until later.