40 hour week

[Mark Ashworth]

Good Day,
XP stipulate that a developer should enjoy an 40-hour week. It also stipulates that at the end of each day the new code written should be fully integrated into the system and should pass all of the unit tests.
Now if a unit test fails and programmer A caused that test to fail by the code he/she added to the system, is it his/her responsibility to remain after work to fix the bug or does it become part of the tasks for the next working day?

[Johannes de Jong]

I only started looking at XP, thanks Frank , but the one thing that I already have a problem with is the 40 hour week.
Where is the cut off. Are the hours spent learning ie. writing Java programs at home, included in the 40 hours. They are not actually hours spent on the project but the hours spent will mean that you know Java for the next task, which might be a Java project.
[This message has been edited by Johannes de Jong (edited April 03, 2001).]

[Junilu Lacar]

Mark,
You might find an answer in Uncle Martin's article on how they do Continuous Integration at ThoughtWorks.
I would think that you would only try to integrate new code that you have completed and unit tested. That is not necessarily at the end of each day because some tasks may take more than a day to complete (including unit test).
J.Lacar
[This message has been edited by JUNILU LACAR (edited April 03, 2001).]

[Junilu Lacar]

Johannes,
This is explained in XPE. The reason for limiting hours to 40 per week is that it is a known fact that productivity decreases when people work long hours over extended periods of time, say weeks or months. You get diminishing returns and that goes against the XP principle of providing maximum value to the customer for the work done.
So, in order to keep people fresh and optimally productive, XP recommends limiting work hours to 40 per week. If you do have to work overtime, then that indicates a problem on the project. If you really have to work overtime, it shouldn't be for two weeks in a row.
I think another reason for the 40-hr week is that maybe people who actually have a life outside of work are more productive at work. If you spend your free time tinkering with Java and enjoy doing it, then those hours just might not count as actual "work".

J.Lacar

[This message has been edited by JUNILU LACAR (edited April 03, 2001).]

[Sowmya Karmali]

Hi,
The 40 hour week might not happen from the word go. These are my views on how all of us can keep that weekend date :
Monitor the number of user stories, not only at the end of an iteration, but also during it, so that for the next iteration, the number of user stories can be lowered.
Project specific learning is also an activity that should be estimated for.In all our projects, project specific learing (technical or functional) is accounted for in the timesheets. In this way there are lesser chances that the project will be stretched for time.
Comments?

[Frank Carver]

This whole aspect of XP is the one I find the strangest. Not because I agree with working long hours, but because I am so unfamiliar with the idea of having to work long hours.
I've been working in the computer industry primarily as a software developer for about 15 years now, and except for a short spell in 24-hour system admin job, I've never really had to work unusual hours. Sure, when I first started hourly-rate contract work, I worked a few 50-hour weeks, but that was only because I could "see" the cash racking up, and I soon got over it.
How about an informal survey. Do you routinely work more than 40 hours a week? What sort of job are you doing that requires this?

[Kathy Shkarlet]

Hi Frank,
to the survey :
I habitually work overtime. What kind of ... - well, I started 8 years ago writing windowing system in C under DOS. After that I flirted with Assembler, DSP, C++ in engineering calculations etc.. and finally found new life with Java There were periods when I was pushed to work crazy hours and periods where I had to ask to be allowed some overtime.
So my responce is - I feel uncomfortable working 40!!! Work hard - play hard!

[martin fowler]

Originally posted by Frank Carver:
This whole aspect of XP is the one I find the strangest. Not because I agree with working long hours, but because I am so unfamiliar with the idea of having to work long hours.

I've often heard surprise at this practice, but like Kent I worked enough in Silicon Valley to see the source of the practice. Too often I would go in on an expensive day's consulting and be able to start doing the work we wanted to do that day until late afternoon. The reason was becuase we spent most of the day trying to track down some bug that someone had put in at 2am the previous night.
In the valley it is often a matter of personal pride that you work late hours. Yet I found incidents like this were common and counter-productive.
One of the things people often miss about XP is how many of its practices are about defect prevention: testing, pairing, 40 hour week, continuous integration, refactoring - all these are about stopping defects getting into the code base. Defects have an immense effect on slowing you down. I learned that in my first job trying to figure out why something wouldn't print out - it was due to a simple CR/LF problem that took five seconds to fix and all day to find. Putting effort into getting rid of defects pays for itself many times over.
Martin

[Frank Carver]

OK Kathy. Do you work "paid" overtime, or "pride" overtime?
I can understand working extra paid hours if you need the income, but to work extra hours for no reward seems like explitation to me.
I know of some people where I work at the moment who get paid a flat rate, but willingly surrender their home life for some imagined benefit of working long hours (promotion prospects, peer acceptance, I don't know why). In general, however, they are not the most productive members of the team; often staying late to produce huge reams of documentation nobody will read, or other pointless busy-work.

[Johannes de Jong]

If I understand it correctly 40 hours because.. you work smarter

[Nikhil Kumar]

I thought 40-hours is just a metaphor meaning work only planned hours. If you need more hours, you underestimated, and there is something wrong somewhere in the process, which needs to be corrected before getting into a similar situation in the future. Or does 40-hours mean 40 hours? Please opine.

[Kathy Shkarlet]

Hi Frank,
My current job is the first one to pay for overtime.
I don't do it for promotion, or documentation reams and I think I am really productive.
Why? - It's bringing me joy and satisfaction. Software allows me to conceive an idea, grow design and be able to share it / see it fly without having to mess up with limitations of other creative activities. As an example - pure mathematics is exciting, but it doesn't really produce "palpable" results. Growing flowers produces very noticeable results, but it takes so long!
Software is the golden point for me.

[Johannes de Jong]

Frank I'm at work 45 hours a week. I get paid 40. Why the extra 5, I recon I "waste" at least 1 hour a day on talking about the latest soccer results they dont follow cricket here , the footh-and-mouth etc.
I came accross the following :-
I don't think the number of hours makes much difference. What defines the difference is volunteered commitment. Do people want to come to work? Do they anticipate each day with great relish?
People have to come to work, but they perform great feats by being committed to the project, and commitment only arises from a sense of purpose.
see http://www.cutter.com/ead/ead0002.html for the full article.

[Johannes de Jong]

Actually Frank I have another question for you. If I'm correct you run your own consultancy firm. How do you say no to your clients when / if they demand more time. Surely not all your clients believe this "40 hour crap" (from their point of view).

[Frank Carver]

Honestly, it has hardly ever come up.
I guess it must be a cultural thing, but in all the development jobs I've done, the clients have never expected lots of hours. On the rare occasions when extra time has been needed it's always been a case of "I don't like to ask, but could you ..."
I've certainly not encountered any "40 hours is crap" feeling. My hours vary according to the days work, I try to complete something before I go home each day, so I might work 37 hours one week, and 43 the next, but about 40 hours per week is assumed or expressed in most of the contracts (and It's not something I have ever had to argue for). In fact, were I to submit a timesheet at the end of a week with more than about 48 hours on it, I would probably have to explain why I had worked the extra hours.

[Johannes de Jong]

I'm employed by a company that contracts me out to its clients. I think that for them its only "how much" can he earn for us. Its also easier then for the client to ask that we put in extra hours. They contact my boss which contacts me, the client does not have to put direct pressure on me. I out of loyalty to the project, my company etc. work the extra required hours.

[Dianne Spillers]

I agree with Frank on the cultural thing. I don't not work for an IT compnay but an manufacturing company with a large IT department. It is rare around here to see all IT workers go home on time. Most of us work 45-50 hours a week and don't bat an eye. 60 hour weeks are common around here too but it is the culture of our environment. If the systems come down the plants and distribution centers are down. Not really good for business.
From the development side, there is alot of focus put on time lines and features. I believe that XP tells us that more features require more time. Sometimes we get the more features but not the more time as a resource which in turn causes the developers to work the extra time to get it done on time. Viscious circle, huh?? My biggest issue with my current project is the constant adding of features but my timeline not getting any longer.

[vaibhav punekar]

Hi,
In India,basically culture of 5-day week ,8hrs a day is not there.(it has started b'cos of software)I think it is because it is multi-cultural and Unity In diversity country where holidays for the various festivals go very high.So if here we start "40 hrs" culture we have to miss certain important festivals.So instead of blindly following "40 hrs" culture it should be according to the culture in the country you are living.So many times I wish to go on saturdays to work but it is strictly closed.It should not be a matter of "overtime" as such.Many people who migrate from other fields to software may need some extra time to cope up with the situation.May be in this tremendous competitive world many people work extra to learn more in less amount of time.In that case"40 hr" culture does not hold good.

[Johannes de Jong]

The more I read on XP : I think the important thing that they are trying to get across in XP is that you should have a balance between work and play. see my comment a few postings back
[This message has been edited by Johannes de Jong (edited April 05, 2001).]

[Frank Carver]

I feel that the XP "40 hour" rule is partly about balancing work and play, but also about basic bottom-line productivity. rested, relaxed people, who have had time away from computers and work are simply more productive. Have you never had that "went home depressed and came in the next day to find that the solution was easy after all" feeling?

[Sowmya Karmali]

Originally posted by Frank Carver:
I feel that the XP "40 hour" rule is partly about balancing work and play,

I completely agree with you, Frank. If I know upfront that I have a fixed number of hours to finish a task then I would probably schedule my activities accordingly. Else, I would say to myself, I'll do it later in the evening or night. I feel the 40 hours is only an issue of managing time professionally. No other methodology lays any emphasis on actual manhours put in, other than XP. Working seven days a week is not going to make things faster for us; if there were 10 days in a week, we'd probably stretch 7 days work to 10.

[Johannes de Jong]

Originally posted by Frank Carver:
Have you never had that "went home depressed and came in the next day to find that the solution was easy after all" feeling?

I can hear my wife shoting YES !!!if i showed her this remark of yours Frank, she has been trying to get me to walk away from a problem for years now

[Frank Carver]

she has been trying to get me to walk away from a problem for years now
Wow! Must be one huge problem ...

[Johannes de Jong]

I'm not thathuge Frank

[Greg Pfeil]

Originally posted by Nikhil Kumar:
I thought 40-hours is just a metaphor meaning work only planned hours. If you need more hours, you underestimated, and there is something wrong somewhere in the process, which needs to be corrected before getting into a similar situation in the future. Or does 40-hours mean 40 hours? Please opine.

Well, from what I've learned doing XP so far, the more you use it, the more you realize that there are no metaphors. For example, the index card thing. A lot of people in another thread were talking about using different things -- Post-Its, looseleaf, etc. However, you quickly find that card stock is about as lightweight as you can get before the material is too flimsy to be put in a pocket, thrown into piles, etc. And much larger than 3x5 (we use 4x6 on my project) gives you too much room to write information you'll never use. So, in the end, index cards is quite literal -- they just happen to be exactly what fills the functional requirements.
So, I think 40 hours should be taken the same way, for a number of reasons.
1) That's what you're being paid for. Unless you've negotiated for some other period (I'd happily sign a contract for a 60-hour week if it meant a 50% pay raise).
2) It keeps you from burning out, and if it's "enforced" (or encouraged, if enforced is too strong a word), there's no peer competition to stay the latest or get noticed by the boss. That can often be the way you get to the burn-out.
3) It doesn't mean you can't program after the 40-hour limit. Just move your head into a different problem space (personal project, consultant contract, whatever) and your body to a different location (that in itself can freshen you up).
4) It makes for more friendly paired programming. If one person doesn't want to stop, the other (leaving after an 8-hour day) may feel guilty for leaving the other behind, or may end up burning out, because he _did_ stay to help his partner. Also, you won't be goaded into working late to "beat another team" or whatever.
Paired Programming and the 40-hour week work well together. If you are in a pair, you both have to work overtime or neither. Programming solo is as bad as programming late. And each of these XP "rules" helps enforce the other.

[Johannes de Jong]

Originally posted by Greg Pfeil:
4) It makes for more friendly paired programming. If one person doesn't want to stop, the other (leaving after an 8-hour day) may feel guilty for leaving the other behind, or may end up burning out, because he _did_ stay to help his partner. Also, you won't be goaded into working late to "beat another team" or whatever.

You make a very valid point here Greg. The amount of work done by the staff involved in pair programmning. If the one is a hardworker and other one not. Surely the fact that the work is jointly owned will create tremendous conflict. Its obvious that one has to really know the people that are involved in a project.
I must say another thing that springs to mind is that Pair Programming could ease the yearly work evaluation one has with the manager regarding increase, education etc. The manager simply gets the input from the people I paired with. He really will know how I performed.
[This message has been edited by Johannes de Jong (edited April 06, 2001).]

[Greg Pfeil]

Originally posted by Johannes de Jong:
You make a very valid point here Greg. The amount of work done by the staff involved in pair programmning. If the one is a hardworker and other one not. Surely the fact that the work is jointly owned will create tremendous conflict. Its obvious that one has to really know the people that are involved in a project.

Although not strictly an XP technique, there are some good ways to avoid hiring people who don't fit into your team (or to hire people who are exceptionally suited to your team, if you want a positive slant on it). I forget the title of the book -- PeopleWare or PeopleSoft or some such, but they talk about a programmer audition. Would you hire a juggler for a circus without watching him juggle? But you hire a programmer without seeing how he works in a team, particularly _your_ team.
Have the guy come in, have your team take a break, and just hang out with him for a little while (maybe lunch at a nearby restaurant) -- this chatting and such should show if they'll work out together, and if he seems interested (for some reason, this approach gets a more positive response than a one-on-one interview), bring him back for a little pre-hire integration testing. You don't have to have him write code for you, but maybe just sit in and participate in a brain-storming session, or some other full-team activity. Letting him get a feel for the team like this not only shows you if he fits in, but also shows him that you're not just hiring to increase head count, and gives him some real incentive to choose you over the guys that gave him a phone interview, but are willing to pay him an extra grand or two.
Note: this won't work so well in huge teams and with dozens of interviews. But, if you're using XP, that should never be an issue in the first place.
An approach like that, while slightly more time consuming, can be a real project-saver later on.
Also, you mention "joint ownership", but in paired programming, you work on different pieces of code every 6 weeks or so, and with a different partner every three weeks or so. So, really, joint ownership isn't really an issue. Although . . .
I seem to remember XP books talking about no ownership, but I'll tell you what; on XP projects, I feel ownership for every single file in the tree, and I'm never about to hand off work to someone else because "that's his bit". If the rest of the team were to be hit by a bus tomorrow, I feel confident that I could introduce a new team to the nuances of our code and style without wondering "why the hell did he do that bit like that?"

I must say another thing that springs to mind is that Pair Programming could ease the yearly work evaluation one has with the manager regarding increase, education etc. The manager simply gets the input from the people I paired with. He really will know how I performed.

Hrmm, that last brings up a certain question in my mind. I've never had an evaluation at this job. Now, I am fairly compensated, have received raises and promotions, and have quite open discourse with my superiors, but there's never really been a direct performance evaluation.
I don't know if I like that or not -- it's nice that it's very informal, and that I don't feel like I have to fight for more pay, but it also seems like if things deteriorate (which I don't expect), it will be hard to initiate some sort of formal evaluation system.

[Johannes de Jong]

Greg when is your company moving to Amsterdam, really sounds like a great place to work for
As fate would have it I noticed an evaluation package of three 3cd on the desk of a colleague. "Tamino X-Studio" from Software AG. competition for you guys Greg?
[This message has been edited by Johannes de Jong (edited April 06, 2001).]

[Bill Prentice]

All of the above leads me to several conclusions.
Flexi-time (which we enjoy) is pretty much incompatible with XP.
Working from home is a no-no.
Developers with external (non-work) responcibilties (familly, life etc) stand out like sore thumbs if they stick to a 40 hour week when other team members stay late every night.
Don't misunderstand, I would like to try XP but my own circumstances would be at odds to the method immediately. My day begins at 6.00 am and I leave at 16:00 because this arrangement suits my personal circumstances (I have an autistic son who needs my attention). Since I can only change this arrangement for exceptional circumstances how do I pair program or restrict myself to 40 working hours. Do I expect the rest of the team to fall into line with my hours.
Nearly all of our developers have to travel\work remotely or work from home when practicable so they are not going to appreciate being office bound.
Okay I know that my situation is not the norm but there are a lot of developers whose circumstances are similarly 'not normal'and XP would seem to expose them unfairly. Maybe the difficulties with reviews\evaliations is a benefit in these cases.

[Johannes de Jong]

I try and work the same hours by the way Bill to miss the massive traffic jams. I will also have the same problem workin in a pair. But I suppose you dont have to work the full day with a partner.
Considering the appeal that working from home has for me I find the fact that XP is not really suited to that type of worker is also one of its (only ??) drawbacks for me.

[Greg Pfeil]

Originally posted by Bill Prentice:
All of the above leads me to several conclusions.
Flexi-time (which we enjoy) is pretty much incompatible with XP.

Well, incompatible with, say, the pair programming bit, but the other aspects could still work quite well. At best, each pair could make a compromise for when they are going to work for the coming iteration.

Working from home is a no-no.

Pretty much -- but in our company, we have plenty of projects that don't use XP, and smaller projects that have only a single developer. Working at home is much better in these environments.
I started a thread on Open Source and XP, asking if anyone knew a way to get around the distributed nature of Open Source so XP could be used. I imagine working at home would pose many of the same problems.

Developers with external (non-work) responcibilties (familly, life etc) stand out like sore thumbs if they stick to a 40 hour week when other team members stay late every night.

I don't agree with this one -- this should eliminate this kind of problem that exists in the "traditional" software world. _Everyone_ will work 40 hours, so the family man feels no pressure to work late, because everyone else is going home too.

Don't misunderstand, I would like to try XP but my own circumstances would be at odds to the method immediately. My day begins at 6.00 am and I leave at 16:00 because this arrangement suits my personal circumstances (I have an autistic son who needs my attention). Since I can only change this arrangement for exceptional circumstances how do I pair program or restrict myself to 40 working hours. Do I expect the rest of the team to fall into line with my hours.

Yes, you are definitely in a situation where flexibility of schedule isn't really an option. However, this could help (although your particular hours are a bit early). At my office, many of the developers work from 8:00-16:00, and when I'm paired with them, I come in then to work with them -- I have the priveledge of no restrictions on my schedule, and while I find it a little rough to come in at 8:00 sometimes, it's well worth it when I head home at 16:00.
Your situation probably won't work well with XP. Oh well, it can't do everything. But try to keep it in mind if you do find yourself in a suitable situation.

[martin fowler]

Flexi-time (which we enjoy) is pretty much incompatible with XP.

Not really. Most people that do flexi time have a sizeable overlap when others are around. And there's usually non-programming work that's okay to do solo. XP is something you adapt to a team. I don't think most XP teams would have trouble adpating to the kind of flex schedule you describe.

Working from home is a no-no.

Yes, this is much more of an issue. Not just does it get in the way of pairing, it also gets in the way of the "all in a room" nature of XP communication.

Developers with external (non-work) responcibilties (familly, life etc) stand out like sore thumbs if they stick to a 40 hour week when other team members stay late every night.

I would think XP would be better than this. Since XP is strongly against long hours - that would be better for people with a life.

------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

[Greg Pfeil]

Originally posted by Johannes de Jong:
Greg when is your company moving to Amsterdam, really sounds like a great place to work for
As fate would have it I noticed an evaluation package of three 3cd on the desk of a colleague. "Tamino X-Studio" from Software AG. competition for you guys Greg?

Well, for the most part, they're targeting a different problem space than us, although we both do have native-XML databases. That's really one of the basic pieces you need for any kind of XML suite, so it makes sense that we'd both have one.
I don't know anything about their product, but I'm sure ours is much better