Decompression Debt

http://marc.theaimsgroup.com/?l=extremeprogramming&m=102270503715640&w=2

If you dive in deep water, the longer you stay at a level the more gases dissolve into your blood. You now "owe" your body pauses at intermediate levels before surfacing. If you surface too fast, you get the bends.

 List:     extremeprogramming 
 Subject:  Sustainable Pace and Decompression Debt (Re: [XP] Re: Weaknesses of XP)
 From:     "J. B. Rainsberger" <jbr () diasparsoftware ! com>
 Date:     2001-12-30 17:33:49

DougPhilips wrote:

 >>From: JonasKongslund? indited:

 >>I think you would lose. Perhaps it just me, but I feel young and energetic
 >>and don't mind coding all day and night.

 >>Coding is fun - combine it with free food like that you can buy in nice

 >>Can this go on for months? I don't think so but one month sounds 
 >>reasonable.

Indeed. Perhaps it is the issue of sustainability that is in dispute. Not bein' "young" anymore, I don't desire to elide the rest of my life just to code. Conversely, when I'm "in the groove" on something I can work 60+ hours a week, because it is fun, because I am "there." In my experience that doesn't happen all the time, but it seems downright stupid to say, hey, I've put in my 8 hours today, I'm going home for no other reason than the it says here I have to go home.

It is absolutely stupid, which is why I prefer "SustainablePace", as it suggests that, as long as you keep coming into work genuinely ready to go, you're not working too much.

I hate leaving little things unfinished at the end of the day, so I generally want to stay late to finish them, if at all possible. My Coach pressures me (a little) to leave right after 8 hours, because he wants me fresh the next day, and he's right. Still, I would sooner come in about 30 minutes later the next day than leave something annoying hanging over my head for the night. I think the latter is more likely to make me want to go in the next day in the short term and more likely to beat me into the ground over the long haul.

On the flip side, when coding is going well, I find it better to go home, relax a little, let the subconscious mind work on the problem a little [related to SoakTime], then be all the more ready the next day. That's just me, though.

The key, though, is that many (most?) programmers don't know what life is like when they go home after 40 hours each week. Once they see how positive the experience is -- both on their productivity and their attitude towards the work -- they can better weigh the benefits of going home against those of staying to finish some extra work without as much risk of BurnOut.

I think that, like all XP practices, you have to do them by the book long enough to understand them before tinkering. I've been doing it for about a year, now, so now I need to know how much overtime I can work before I start to hate it again. At that point, I know my limit, and that should be the "sweet spot". If my sweet spot is 52 hours, then I should be able to work 40-44 hours per week with the occasional 52 and be able to sustain that indefinitely -- at least until my attitude changes. :)

My reading of XP literature suggests that the 40 hour week is a defense against employer pressure to produce and not employee interest level.

Not quite. It's a way to pay down "DecompressionDebt", just like refactoring pays down DesignDebt. The more overtime you work, the more "decompression" you need in the form of vacations, short-hour weeks and "dead air" (time spent at work not doing anything useful -- or worse, doing actively stupid things). If you never need any decompression, you can continue indefinitely. Sometimes you need to steal some hours now (to finish a project) in exchange for extra decompression later.

The problem is that most projects rack up the debt and only make the minimum payment -- they try to do a bunch of little things to keep the overworked programmer happy without solving the problem that made him unhappy to begin with. As a result, the programmer begins to cost more and more to keep: bigger raises, more "personal days", more inactive time at work, negative effect on others, and so on. Now the programmer costs more than he's worth, but there's no easy way to recognize that -- after all, as a person moves up through the ranks, he should make more money and do more high-level jobs, right? (Employers are suckers.) You're now paying a programmer for the privilege of watching him complain about his work to others, who then begin to doubt the company. A mass exodus is in the works at the cost of probably $1M in training. Is this the way to run a business?

If you can find a long list of genius programmers to save your ass on each project, then throw away once they begin to cost too much, then you're fine. Unfortunately, there aren't more geniuses, but there are many more projects -- eventually, you won't be able to get enough geniuses to replace the ones you threw away, especially once enrolment in computer programming programs goes down as a reaction to the shrinking market for programmers! End result: you have a bunch of idiot programmers and a job to do, and no amount of borrowing against decompression time will get the job done.

Better, perhaps, simply to get your best people working at their "sweet spot" pace and burn out the crappy programmers. Unfortunately, if you leave everyone to their own devices, the crappy programmers won't burn out (they don't do anything, which is why they're crappy) and the good ones will die young. The irony!

If you are a good programmer, work six consecutive normal weeks (40, 37.5, whatever your local number is), then see what you feel like in the mornings. That's the feeling you want. Now work the way you think you should. When you stop feeling good in the morning, work less until you feel good in the morning. If you know a good programmer, *make* him do this. He'll thank you.

And yes, when Transarc Corporation (since bought out by IBM) was hiring in its early days, the contract required 50 hour work weeks. The deal was that the stock options would make the extra time worthwhile, and also that no one would be asked to work more than 50 hour weeks. Not to say that some didn't, but the early days had an atmosphere of excitement which was contagious and motivating.

Was this because many of the people didn't know any different? Your statement that they dropped the policy once priorities changes makes me think that that's the case. Your people could have been sitting on a local maximum of happiness, unaware that the absolute maximum is even higher!

 =======================================
 J. B. Rainsberger,
 founder, Diaspar Software Services Inc.
 ExtremeProgramming for the JavaLanguage platform
 Let's build software that people understand.
 http://www.diasparsoftware.com/

I have used DD to mean "DesignDebt incurred via schedule constraints & all-nighters that emphasized features over structure". The goal during such sprints is features over code of a quality within the abilities of the coders. When the code decompresses, over a more normal coding cycle, we pay its DesignDebt. Or we toss it. -- PhlIp