Loading ...
Sorry, an error occurred while loading the content.

44288Re: On wanting success (was Re: [XP] cons of XP -- on "success")

Expand Messages
  • drawstho@aol.com
    Mar 1, 2002
    • 0 Attachment
      Ron Jeffries <ronjeffries@...> writes:

      > Around Friday, March 01, 2002, 1:39:40 AM, drawstho@... wrote:
      > > Let me chime in on this issue. I don't think it has anything to do with wanting to succeed or not. I
      > > think that it has to do with discipline. People want to succeed, and may even know how to succeed, but do
      > > they have the discipline to do it? XP requires that each member of the team develop the discipline to
      > > stick with the practices.
      > "You keep using this word. I do not think it means what you think it
      > means."
      > Well, actually, I'm halfway between you and Kent on this one. As you
      > surely know, he doesn't agree that XP requires discipline.
      > I think it takes discipline to learn it but after that it is just what
      > you do.

      OK, then it takes discipline to learn it - many never will...
      > > IMHO, one of the reasons for high-ceremony processes is that they
      > > try to replace individual discipline with process discipline, which
      > > is enforced by a QA group, normally. This means that not everyone
      > > has to have the discipline to do it right, just the process
      > > police...
      > Which doesn't work because no one pays attention to the process group.

      It often works. Airplanes fly, don't they? It often fails. IMHO, this is 1. because the team is not even disciplined enough to follow QA's advice or 2. QA doesn't know what it is doing - and my vote is usually on 2.
      > > So, agile processes are quicker, cheaper, and more responsive, but
      > > require more disciplined people. High ceremony processes can get the
      > > job done with less disciplined people, with a higher cost in both
      > > money and time.
      > That's the theory. I think it's not obviously true, for two reasons:
      > 1. In the high-process form, it still only works to the extent that
      > everyone does what they are supposed to do, so the workers still have
      > to behave according to the discipline, even if it is forced, and there
      > is definitely MORE discipline going on.

      Absolutely - any project can be made to fail. Sometimes there is not enough time or money to get the job done - isn't this the basis of one of the main selling points of agility? ...at least you get something for the money you spend...
      > 2. High-process approaches work abysmally poorly unless they are
      > really adopted by the real workers. This fact tells us that it is
      > still what the workers do that counts.

      No question - see above...
      > Workers on an XP project do less weird stuff. Therefore, less
      > discipline. Mostly they do what programmers are supposed to do: test,
      > code, design, analyze, etc. And they do it in a form that is quite
      > close to what we find in the wild.

      It's all in the perceptions. Until someone tries them, the concepts of TestFirst, RelentlessRefactoring, and PairProgramming seem pretty weird. For for some, they may always seem weird. Now, I think they're reasonable, but I'm not the basic 23-year-old right out of school... or the converted COBOL programmer... or the guy who's been writing C and Assembler for 20 years... or the hard-core database developer... or the manager that has been these things and is trying to decide if XP is for him/her.
      > Therefore XP requires less discipline, not more, than high-ceremony
      > processes. It works as well as it does, arguably, for exactly that
      > reason.

      This is precisely where we disagree. A high-ceremony's discipline is externally-imposed on the Developers - all they have to do is follow the directions and they're doing their job. In an XP team we leave much of what the Developer does up to them. They have to decide what to do, when to do it, how to do it, and so on, to a much greater extent. The individual coders have to fight their urges to dominate the pair or program alone, they have to fight the urge to violate YAGNI, and so on. This takes internal discipline. For some this discipline eventually becomes second nature, but I fear (there's that word) that it doesn't for all.
      > > As I said before, think Special Forces A-team versus regular infantry... this analogy works for me - but
      > > I'm a soldier...
      > Do the special forces guys do what they do because they have
      > discipline, or do they have discipline because they do what they do?
      > Or do they just do what they do, and it happens to be really good for
      > special forces work?

      They do what they do because they have the personality to be able to do it, and the Army recognized that and trained them to do it... it's all personal discipline and drive... the idea is that the job requires personal discipline, so you must choose those that have it and weed everyone else out. The military is more about choosing the right person for the job than training somebody for the job... in this way I think it is like XP - successful XP teams must self-select, you can't make XP work for every team. (this does not mean you can't make any team more agile, just that you must work within the inherent limitations of that team...)

      Dan ;-)
      > Ron Jeffries
      > www.XProgramming.com
      > The practices are not the knowing: they are a path to the knowing.
      > To Post a message, send it to: extremeprogramming@...
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      > ad-free courtesy of objectmentor.com
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Show all 98 messages in this topic