Is Xp Overclocked

I resuscitated parts of this page. The analogy is too useful to overlook. -- Alistair

(I thought I'd tidied this page, but it appears I tidied ProgrammersBurnout. These two pages are very similar - could someone combine them?)

OK, but the analogy limps seriously. I no longer support the analogy, which I created. XP projects don't run hard or hot. They DO require high discipline in my opinion, but some disagree. -- RonJeffries

Perhaps I need to catch up with all goings ons in XP because I never really saw it as requiring high discipline which tells me there needs to be a disciplinarian which tells me there's a master plan. I think if XP as a piecemeal process. Is that wrong? If it isn't, I'm not convinced yet that it makes it easier to succeed on projects. Projects are all about people. That's why projects of all kinds fail or succeed for various reasons. I can not use XP and succeed because I've got the right group of people. But I can use XP with the discipline approach and fail because I've got the wrong group of people. Nicht wahr? -- PhilipEskelin

You can fail in any number of ways. You don't get to say you failed "doing XP" unless you were following ALL the practices, not just some piecemeal set that seemed reasonable. They're useful one at a time, mostly. But XP, as we've defined it, is all of them. I'm reporting here my experience that if you slide away from some practices, you get a disproportionate drop in productivity, and looking for good ways to detect early that this is happening. And reflecting on whether or not it should surprise us that the disproportionate drop occurs. --rj

Excerpt...To me, the suggestion is analogous to "overclocking" a chip. You can take a chip that runs at 200 MHz, and maybe push it to 250 or even 300. It'll run hot. Sometimes if you go too far, it'll crash ... but it can go like a banshee.

An overclocked methodology might be particularly "cuspy": a little deviation could take you way off track. As the guy on top of this one project for so long, I am inclined to agree with this. When it's clicking, we can really kick. When we go off process, however, we seem to hit the weeds rather quickly. (Alistair -> never mind the strong phrasing, the idea is what I'm after)

If it's true, what's the lesson? I suggest that the lesson is that if you're going to try XP, you have to really monitor the signs that you're going off the road. You have to do it all, you have to stay right on top of your game. If you don't, you'll find that you need more documentation, more process, with a resultant slowdown, to stay effective.

-- RonJeffries

The reason I resuscitated this page is that both Ward and Ron have mentioned some of the same effect to me. Ward described something like burnout in the team members. "After two years of delivering every few weeks, without any variation in the pace, we just felt tired..." or something close to that (Ward, you are welcome to add to or edit, since I am recalling your description). At the time he said that, I didn't have any place to file the sentence, so I just left it in some storage bin in my head. Something about variation and change of pace being needed for healthy happy programmers. Makes some sort of sense.

The overclocked chip analogy is strikingly similar. Indeed, if you drive a chip at a higher clock frequency, the chip gets hot and things start to happen.

So I would like to keep the analogy alive, and see what people think. Ward's and Ron's two projects are the only projects I know of that have this characteristic, of delivering regularly, every month, for several years in a row.

I wouldn't ascribe this as a failure of XP, rather, I would ask something about the human need for change of pace. Any takers? -- AlistairCockburn

FWIW, this reminds me of something I've seen in the past. A consulting company I was involved with in the past that did custom business applications using a fixed-time/fixed-price model used to overclock people.

They had different phases of the project lifecycle. Most of them were sales tools that sold the client to the next phase, except the development phase where they truly had to deliver something.

One of those phases was called a rapid solutions workshop. A team of about eight people spend a week with 6-10 clients in a conference room hashing out a prototype that's displayed to executives on the final day. Parallel to this is a sales process going on behind the scenes by executives on both sides.

A week prior to this, the team spends all week trying to get their hands around the problem and in determining which key scenarios they would use in that demonstration. They work an average of 80 hours that week.

The next week, if they went home the night before and caught a few hours of sleep, they show up at 7am and prepare for the day until the client arrives at 9-9:30am. The meeting goes on all day with facilitations (what are they?), note taking, prototyping, etc. When the client goes home, the consultants stay and work till midnight, 1, 2, 4, or all night and all the next day.

My point is that you can do this workshop but your clock is running over speed. By the end of that second week you are a punchy, babbling idiot. Usually you go home and sleep almost the entire weekend in an attempt to reset yourself. I think it's all by design.

-- PhilipEskelin

Is there something in XP that says anything like "Pairs must program together for a minimum of 60 hours per week"?

"OverClocked?" is a fun analogy, but does it apply to hours worked?

Could a "mellow team" exist that would be doing XP 30 hours a week?

Would XP be any less "OverClocked?" for this team?

I quote the great Egyptian philosopher HermesTrismegistus "As above, so below". Or in other words patterns and rules can and should be applied at all levels. Just as we are MovingPeopleAround with in a project we should also do so at a meta-project level. Move people to new projects, move entire teams between projects. If there were more than just a few projects using ExtremeProgramming such that people could move around at the meta-project level perhaps less burn out would occur. -- DonWells

To answer Alistair's challenge - the European solution is to take 2-4 week vacations every summer. Ron and Ward- what were the vacation practices on your projects?

I can't remember the last time anyone I know ever took a 2-week or longer vacation. One week summerish, and one or less around the Christmas holidays is more common. The Christmas one isn't much like an actual vacation, in my own experience. -- rj

And the Silicon Valley solution seems to be to change jobs every two years or less, sometimes with a break in between to overcome the burnout. This seems suboptimal, and was a surprise to me. In Australia we have more European-like habits. -- SteveHayes

More ExtremeDiscipline discussion moved to that page. -- Alistair

Now that we're back on this topic, I'd like to comment on RonJeffries not remembering when someone took a greater than 2 week vacation. Wow, you guys must really be in a vacuum up there!! ;-) ;-) I work with people of many different cultures and from many different countries. Sometimes I travel to their country, and many times they work with me here in New York.

What I see is a common theme amongst people from Asia - and to a lesser extent Europe - who take three weeks up all the way up to two or three months of vacation at a time to go back home and visit the family, or travel around the world, or spend an extended amount of time cooling off in an exotic location. They seem to be more comfortable doing this than the stereotypical American. So perhaps these are popular cases that thwart ExtremeDiscipline. -- PhilipEskelin

Excuse me, I wasn't coming out against vacation, I was reporting the fact that in most of the environments I recall, most people didn't take two-week vacations. I'm all for vacations, they clear the mind, replenish the soul, and fatten the belly. -- RonJeffries

CategoryExtremeProgrammingDiscussion