Subj : Re: extreme programming (thoughts) To : comp.programming From : Phlip Date : Thu Jul 21 2005 11:08 pm Alf P. Steinbach wrote: > As usual you didn't or was unwilling to see the point. It was a generic accusation. Sorry. These XP threads will be full of bashing from folks with no idea what they are talking about, unlike you. Yes, XP is indeed like the emergent communism system proposed by Marx, and never implemented. > > Anyone who has done real development has XP experience, because XP was > originally an attempt at capturing real development practices. > > The problem with XP as "XP", putting a name to it and trying to define it, > wrt. to producing quality or anything at all, is the attempt at reducing > intelligence to simple imposed rules, a "methodology", which is just urine, > and therefore also very popular with pointy-haired persons. XP is an initiative to discover the minimum process, based on simple "rules", with the maximum return. As such, it's very hard to discover in the wild. You have to _let_go_ precious things like design documentation, separate offices, long hours, etc. Some teams can't, and some teams try "a little XP" and get screwed up. Crossing the mountains and descending into the Promised Land is very hard, and requires good books and coaches, else you will settle for a marginally arable land in the hills. Many productive teams do indeed find a good process. Now their goal is to express what they do in terms that other teams can apply. For example, some teams have Stand Up Meetings, and some don't. Stand Up Meetings have never been XP canon, and minimal processes _might_ not need them. So you can't write a book and say "thou shalt Stand Up, and write no comment", if that doesn't work for everyone. The goal is to write a book with the critical stuff in it, so secondary stuff like Stand Up Meetings can ... arise if we need them. XP is a stack of very simple rules that fit together to form complex emergent behavior. Matt's post is a _textbook_ example of how implementing only some of those rules, without their balances, will rapidly devolve. I'm not sure what they are missing, but at a guess from the first post it might be... - poor refactoring, test-side - poor refactoring, in general - no acceptance tests - QA is not collocated - low "onsite customer" involvement - poor integration When those go down, new tests and code grow hard to write, so they add more bodies. (10 on one project???) When those go down, integration defects occur, and QA catches them. Then, because business rules are not encapsulated in acceptance test, we need even more Code Monkeys, and they create even more bugs. -- Phlip http://www.c2.com/cgi/wiki?ZeekLand .