Subj : Re: extreme programming (thoughts) To : comp.programming From : Phlip Date : Thu Jul 21 2005 10:57 pm matt wrote: > i work for a big bucks credit card company. they brought in "coaches". > i wasnt in on the initital project w/ the coaches, but this the > knowledge our xp consultants are passing on to me now. they have it > wrong?? that would be a Good Thing (tm), imo! Matt, you have uncorked a bunch of XP-bashing, as usual, and I will do nothing to prevent us from fanning it. However, it is indeed interesting that you are getting this downstream from pro-coaching. Their job was to make sure y'all make tests easy to write, so you can spend most of the time using them to push in features. Your test/code ratio should be 3:1, but the time between tests and code should be around 1:1. I think their quality went down, and they added bodies (you) to the project instead of cleaning up the quality. The bug rate from QA would seem to bear that out. Does QA help write the acceptance tests? "What's an acceptance test?". Right. > thank you for your comments. you have some good points -- the bugs > found in QA post unit-testing due tend to be module-to-module type > problems. So your team has responded by increasing the number of "unit" tests that put together several modules, right? Another mis-coaching thing: Test cases don't need to only restrict themselves to one module. TDD should not produce "unit tests" that only test one unit. > i could conceide that programmatic unit-testing is not necessarily a > bad thing. but i think thru my first exposure to it -- in a paired > programming, no personal space environment, i was down on it. Done right, it gets as light and rapid as ping-pong. TDD makes pairing bearable. > i think my criticism may be more toward the rest of XP... i generally > dont like things that turn me more into a code-machine than i already > am. really not keen on striping away my desk, individuality, etc. > socially, i believe XP is bad for humans. The majority of programming should be thinking, not slamming in miles of code statements. So, again, are you refactoring the code to keep it easy to change? "Code Monkey Antipattern", the need to type similar code over and over again, is a sign of poor design. > i also think the paired nature of it makes it more expensive than > straight dev -- considering that you have 2 devs doing the work (this > is compared to 1 dev, normal error handling and/or logging, QA people). > generally, my bug hunts dont last as long as your poor colleague's > experience! That's very easy to measure. Over time, pairing is more efficient than soloing. A former colleague once told me, "I'm going back to Las Vegas this weekend. Don't laugh - I'm ahead on my lifetime balance." I asked, "Did you subtract the cost of airplanes and hotels?" Pairing is more efficient than training newbies offline, catching bugs in QA, designing on paper, etc. all totalled together. beliavsky wrote: > You have explained well what is wrong with extreme programming, but if > you want confirmation that it's a bad idea, I suggest the book > > Extreme Programming Refactored: The Case Against XP > by Matt Stephens, Doug Rosenberg > Apress (2003) Matthew wrote: > ill check that book out, thanks. You will find it has almost nothing to do with XP, per the "taking out my frustrations" concept. It will not even address the quasi-XP . It is essentially a sick game played with the verbiage used to promote XP. The authors have never ran a real XP project. You may also want to read their next book, /Agile Development with ICONIX Process: People, Process, and Pragmatism/. Short iterations, lots of collaboration, lots of tests, just-in-time requirements, etc... John wrote: > As far as unit testing goes, there is an upfront cost, but the benefits even > in debugging your code is enormous. IMHO; not unit testing will be in the > near future, if not already, a sign of incompetence. Way. Not just in people, but in products. The test-hostile systems and libraries will fall by the way-side. Including many systems designed to "make debugging easy". Prevention is better than a cure. -- Phlip http://www.c2.com/cgi/wiki?ZeekLand .