Andrew Lentvorski wrote: > Lan Barnes wrote: >> RAD. XP. Agile. Not much daylight between 'em. > I disagree. RAD vs. Agile, sure, not much difference. > > XP, however, is RAD/Agile with Purple KoolAid(tm).
I kind of think of it as RAD/Agile on meth (with all the good and bad connotations that go with that). > XP advocates drive me up a tree. _____ advocates drive most everyone up a tree. > First, the leaders are all a bunch of *FAILURES*. Sorry, that's just wrong. The leaders of XP (Kent Beck, Ward Cunningham, Ron Jeffries and perhaps you want to throw in Martin Fowler) were all very successful even prior to the genesis of XP. > The CCC project that spawned all these Smalltalk weenies who > advocate XP got shitcanned. Somehow people don't seem to notice > this. I don't want advice from someone who failed at what they > are giving advice on, thanks. A project getting canceled doesn't necessarily mean those involved in it or their methodologies were failures. Projects get canceled for a lot of reasons, sometimes due to failure by the development team, but sometimes independent of the success or failure of the team. In the CCC project's case, the purchase of Chrystler by Daimler-Benz played a significant role in the project's demise, not to mention the fact that the project was a fixed-price contract job that was already behind schedule and over budget (think of the success rate of projects once they are in that state) before Beck showed up and started introducing XP practices. In general, even on "failed" projects, if you've got a process and a team that is working well together, you can feel it and you know it. Heck, that's how most people start out: you don't have any good practices, so unless you get paired up with someone how does, your initial projects are almost inevitable failures, but you notice what works for you and what doesn't, and hopefully you learn from it. > Second, "Everything has to be done together to work!" No. Good > engineering principles stand on their own. Yes, good engineering > principles can sometimes multiply their effects when done together, but, > even when done in isolation, they still work better. This is *not* true > for XP. XP is based on well established principles in the software business. It does take those principles to "extreme" lengths, to the point where there are negative consequences if you don't employ other principles to mitigate their impact. Really, most good development practices can be shown to be harmful if you put them in a sufficiently bad context. You need other good practices to create a functional ecosystem. One might not notice this because you tend to develop and select practices based on your current context, throwing out the ones that don't fit with it. It's hard to argue having unit tests, until you have them defied by a code base that completely ignores notions of unit encapsulation. Then they simply become a burden that saps productivity. XP has a lot of limitations and shortcomings (more so than your typical methodology), no question, but that merely limits the contexts where it can be employed successfully. --Chris -- KPLUG-LPSG@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
