Some personal revelations inspired by tonight's BayCHI talk
Eight years ago I discovered Visual Basic 3. At the time I had only ever used simple imperative languages like GW BASIC and PC Logo so the ability to create user interfaces via direct manipulation was both impressive and addictive. About a year later, after having tried to build a customer and sales management system and failing miserably, I became
( Read more... )
Your first paragraph is actually a common misconception that arose from the ironic origins of the 2 methodologies. The "Rational" process for building good software was invented by the design engineers but is actually best applied to the process of programming while the agile approaches (like XP) were invented by the programmers but are actually bets suited to design engineering. Cooper covered this in his talk but I didn't reproduce everything he said in my original entry.
Well, I've spoken with some of the people who developed the RUP, and I've discussed XP in detail with Kent Beck over drinks and not discussed Agile with Alistair Cockborn, although I did help him find his way around a conference because he had an eye infection and was doped the fuck up... (I too tend to get dinners with the keynotes at conferences). I've used both, although Kent would suggest that you're not doing XP unless you're following *ALL* the steps suggested.
That said, I don't think anything I said in my first paragraph was wrong. Rational's current implementation of RUP tools may be heavily oriented towards the programmer, but the RUP itself, and things like the 4+1 architecture models are about design, and are meant to be as implementation independant as possible.
I'll not talk about the Agile process specifically, because I'm a bit rusty on that, bt XP itself is design based on testing and programming. However, it's meant to readily be converted into abstract designs using tools (like Rational Rose, for example) so that between an effective means of transforming code into visualization, and the fact that requirements are captured in test cases, you have most, if not all of the artifacts espoused by the RUP being automatically generated. However, XP remains, at its center, based on implementation, and is all about programming and the programming language (although it can be effectively used with most, if not any programing language).
Now, I assume you were actually talking about my second paragraph, and above I've just disputed some of your assertions about the processes used (hey, ROP is slightly leaning towards architecture, but not at all entirely, and XP is very much leaning towards design). However, I firmly believe in a mixxed approach, pushing the RUP for early architecturaly design, but going to an XP type approach immediately after, and early on, iterating through them as appropriate. Architecture docs are easier to maintain, XP code artifacts essentially maintain themselves. The realm of the software engineer is creating both architecture and design (and partaking in elicitation with the stakeholders). Programers should not invlove themselves in the architecture and design beyond indicating what they can and cannot do , and what restrictions they forsee (although any good designer should listen to their programmers if they appear to have a good idea).
Reply
He is adamant that "release early, release often" results in a lousy user experience and a lot of expensive code rewriting.
Reply
XP isn't XP if you're throw-away prototyping.
Read http://www.objectmentor.com/resources/articles/RUPvsXP.pdf for a nice blurb on RUP and how XP grew from a minimal implementation of RUP. I don't endorse everything in this paper, but it'll maybe give you a better idea of what I, and the rest of the Software Engineering community, are talking about.
http://www.martinfowler.com/articles/newMethodology.html is by one of my heroes, Martin Fowler (who I've yet to meet), and he discusses the methodologies of various people, Beck and Cockburn in particular. There are some links to XP resources there, and I reccomend a quick look before continuing to speak of XP as a means to throw-away prototype.
One of the advantages of the Software Engineering discipline is that we all read the same books and use the same language. Unfortunately, a lot of the terms have been popularized and frequently get misused, even by people speaking at conferences as name-dropping to add credibility. I think that if Cooper had a good solid look at some of the stuff written about XP, or at least Fowler's extremely enlightened analysis of the various methodologies, he'd not be so quick to criticize.
Reply
Thanks for the link about RUP and XP - I'll read it tonight.
Reply
AHEM: Cooper is keen on perpetuating the idea that clients are too stupid to ever come up with what they want, and the solution is to make those decisions for them, and instead of dumping that responsability on the developers, he espouses a new bunch of people, interaction designers (or whatever) to make decisions for stupid clients who can't do so themselves, and then work that out with the developers.
Beck, an optimist, believes that by working with clients and forcing them to work with developers, one can either determine early whether a project isn't feasible, or develop a relationship that will be very fruitful once the users understand what the developers can do for them (and thus can ask for things better) and the developers can better understand what the clients want (and thus can listen better) and you can benefit from all the nice synergistic thingies associated.
Cooper says Beck is wrong because people are stupid, Beck says people aren't stupid. Cooper says change is a sign of aging, and kills software. Beck says change is the environment, and software that takes that into account doesn't age quite so badly, and can even thrive.
Note that on page 8, Cooper says:
During the detailed design phase, the interaction designer works closely with the programmers. There's a crossover point in the beginning of the design phase where the programmers work for the designer. Then, at a certain point the leadership changes so that now the designers work for the implementers. You could call these "phases"-I don't-but it's working together.
Did he not realize what he said? He's so indoctrinated in his own dogma that he doesn't even realize it. You called it a phase, then you say you don't call these things phases!
After reading that, Alan Cooper is a twit who doesn't get it.
The only problem I have with XP is that I'd like to formalize the story writing a bit more to get a bit more of a stable architecture document out of it. Not a permanently stable document, but one that can change week by week with the design. The SAD should be simple, but I think it helps visualize an important aspect that might be otherwise missed with just the story writing... however, Cooper suggests a static SAD, and that REALLY defeats the purpose.
I love how Cooper suggests that our field isn't an engineering field. Fuck you Cooper, I am an Engineer. I can't always prove that my software works yet, the tools aren't there, but I can often prove it doesn't!!
ramou
Reply
Leave a comment