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

Re:extreme programming

[Anonymous Coward]

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"

What's in a name?

[oni]

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.

Re:What's in a name?

[Xavier Shirin]

These two things give me nightmares remembering customers who have had cute ideas at the last minute.

The entire point of having a customer on-site is to hopefully let them have a better idea of what is going on with the project, so that they won't try to suggest anything stupid. At least, that's the theory.

Re:What's in a name?

[oni]

The entire point of having a customer on-site is to hopefully let them have a better idea of what is going on with the project, so that they won't try to suggest anything stupid.

ever tried it?

The specific nightmare I was thinking of involved a customer looking at a report from a database and saying "that looks great but highlight this person."

Now I'd be happy to highlight people who match a particular criteria - you know SELECT * FROM foobar WHERE X=Y and all that. But he couldn't give me any criteria. He just wanted this guy's name highlighted. I could have screamed! I ended up putting a column in the database called highlight.

Keep the users far, far away from me thank you.

Re:What's in a name?

[mshiltonj]

I'd be happy to highlight people who match a particular criteria - you know SELECT * FROM foobar WHERE X=Y and all that. But he couldn't give me any criteria. He just wanted this guy's name highlighted. I could have screamed! I ended up putting a column in the database called highlight.

This is my world as well.

True Story:

When I first started in programming (which isn't that long ago) the alpha geek at the time made a comment that he hates other people using the software he writes.

I was taken aback by the statement. I said to him: But isn't that why you write software, to solve problems and help people do things?

He replies: No, I write software because I like to write software. I like doing cool things. When users start using the software, all they do is complain and ask for more features.

I didn't reply, thinking it was a pompous thing to say.

How little did I know then.

This alpha geek is no longer doing applications development (which he said was "boring") and is now doing linux kernel hacking for embedded systems, I believe, where I'm sure he's doing a great job.

I'm by no means an alpha geek, but I now understand his position. I don't fully agree with him, but I do understand.

Re:What's in a name?

[pong]

Sounds to me that

1. You are not very sensitive to the users needs
2. You give up to fast analyzing your users requests

Maybe you should be doing something else with your time?

Re:What's in a name?

[oni]

I said
These two things give me nightmares remembering customers who have had cute ideas at the last minute.
then I said:
[for example] he couldn't give me any criteria.

and you suggest:
You are not very sensitive to the users needs

makes me wonder what your customers are like. The people I'm used to dealing with have no idea - really absolutely no idea - what the effect of a last minute change will be.

Maybe we should move this discussion to the abstract. Imagine you are building a bridge. Far into the project your customer absentmindedly remarks how cool it would be if you could ad a revolving restaurant on one of the towers. You explain why that's Not A Good Idea (TM) and they give you the deer in the headlights look. The fact is that the average people doesn't think through all the ramifications of their suggestions. How do you think that damn paperclip got into MS Office? Should we 'sensitive' to all these requests or should we be realistic?

This is what I'm used to seeing, and judging by the other replies I think that must be typical.

Re:What's in a name?

[Arandir]

I have to agree with your assessment of the name "extreme programming". Even worse, when you ask five different EP advocates what it's all about, you get five different answers.

One common thread seems to emerge though, and that is an intense focus on coding. Face it folks, coding is the *easy* part of programming.

Thats just the point

[SimonK]

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.

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.

Have you considered ...

[SimonK]

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

Framework designs

[deblorvayn]

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.

Some clients can't handle interaction design

[jumpfroggy]

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?)

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.

Re:Some clients can't handle interaction design

[egeorge]

I think this is why Cooper advocates the Interaction Designer role. That person would spend time learning the needs and challenges of the customer, but wouldn't actually be the customer. They would be trained to visualize software solutions based on what they learned about the problem. In the kitchen example, somebody with a good eye for spatial relationships might have been able to spot the problem with the island before it got built. It is just a matter of asking which is cheaper, prototyping or having an expert visualizer. It is not quite a fair comparison since visualizing software is much more difficult than visualizing physical objects. On the other hand, prototyping software is much easier than prototyping physical objects.

I agree with Cooper that having Interaction Designers this would dramatically decrease the amount of time spent doing design work because you would get good design in fewer iterations.

I also agree with Beck that there is no substitute for rapid iterations and prototyping. If you give good prototyping tools to the Interaction Designers, then they would work their magic and show a prototype to the customer in the 1-2 week time frame of XP. Then hopefully, you would be able to start coding after you had a couple of prototypes that the customer agrees with.

Re:Some clients can't handle interaction design

[Fencepost]

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.

As I understand Cooper's base from his books, he's a strong advocate of making that demo a narrative. Further, he's a real proponent of making it a narrative based on a specific "person" who's using the system. There's no "the user clicks here," there's "Bob clicks on the Continue button." "Bob" is described in detail elsewhere - he's an accountant in his early 40s, has been with the company for 20 years and has spent most of that time using terminals connecting to mainframes and minicomputers. He did some work with spreadsheets on IBM PCs back before IS set up minicomputer access for the accounting department.

That kind of information is at least as important as your interface when you're putting together a system, because it's going to have a dramatic effect on acceptance of the system. If you think that acceptance by fiat ("You will use only Microsoft OSs on the company network!") is going to work, go check around your offices and find out how many covert *nix/BSD boxes are floating around. It won't work any better for general office staff than it does for the geeks.

Not new

[Martin S.]

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_ gc i214246,00.html

Re:Not new

[Twylite]

Have you even looked at extremeprogramming.org [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.

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 !

I wonder...

[ameoba]

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

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.

Danger of out of context quotes.

[Martin S.]

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]

Re:Danger of out of context quotes.

[sohp]

There's no intended implication that Cooper can't deal with programming in the real world, just that his view of organizational change isn't consistent with the Extreme Programming approach. If we could all pick and choose from a variety of organizations that are not dysfunctional in one way or another, or if as software engineers we were able to involve ourselves and influence organizational change in the way Interaction Design espouses, we would be fine.

Cooper's core proposal, when you get right down to it, is reasonable except for the part about requiring the organization to be able to plan up front for things that will change.

To view XP as an abdication that "papers over the cracks" is to discredit the motivations of programmers -- both staff and contract. Extreme Programmers desire to find a way to achieve business goals within real-world constraints, yet also include quality, or "excellence" in development. But the philosophical angle is perhaps best expressed by The Manifesto for Agile Software Development [agilealliance.org]

The parallel with architecture

[chris_mahan]

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.

Re:The parallel with architecture

[funbobby]

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.

Re:The parallel with architecture

[chris_mahan]

I hear you.

The important thing is for people to realize that the more fries you want, the more the bill is going to be. There are no free refills.

Interation Design

[SimonK]

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.

Style over substance.

[Martin S.]

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.

Business people need to deal with their own proces

[jackcaj]

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;-).