The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Typical developer workweek

I'm pulling a schedule out of my a -- I mean -- well, you know how it is, I'm taking a guess at how long it's gonna take to do some work.  I'm trying to get an idea of what a typical developer's workweek looks like (preferably at a small company).  Or at least some idea of how many real developer hours there are in a day (meaning hours during which code is being designed or worked on).  My gut feel tells me it's about 3 or 4, but I'd like to get some outside input.

Background: I think about time in terms of "developer hours", meaning "if I sit down and code this, how much time will it take me just for the coding/testing/debugging?"  I don't count meetings, research, emails, and other activities in that mental estimate, but they take up a lot of time.  So I need a scaling factor that I can apply.  So I can say that a "3 developer-week" project will actually take 6, or 8, or whatever, calendar weeks.
Should be working Send private email
Wednesday, October 13, 2004
I believe the general practice in my company is to take your estimate and triple it.  Noone EVER complains that a project was completed too quickly.
computer junkie
Wednesday, October 13, 2004
The standard algorithm is to double the number and select the next larger unit of measurement, i.e: "a couple of days" becomes a 4 week estimate.

I think it actually shoots low in practice.
Wednesday, October 13, 2004
How many "developer hours" in a day?

At 2 small companies I've worked at, my average is (currently) about 7 or 8.
At 2 large ones: 3 to 4 (it is a sad day when you come back from the meetings and it's already 5pm, and you still have 50 e-mails to go through).
Employed Russian Send private email
Wednesday, October 13, 2004
Multiply your estimate with pi.
Glenn. B. Hansen
Thursday, October 14, 2004
So you can draw circles with it?
Thursday, October 14, 2004
In a small company you'll probably need to get in a few more hours per day than 3 or 4. This is a bunch of people running a tight ship, not a monolithic organisation. You get additional responsibilities in a small company that lead to great experience and can actually shortcut your trip to the top, but you need to return the favour with a greater than usual commitment to the wellbeing of the company.

If it's anything like the small businesses I've worked in, it wasn't so long ago that it was a "family company". Perhaps it still is.

Small companies demand a greater time commitment. Their cultures are tight-knit and you can't be seen to be "dragging the chain" or you risk being sidelined and ostracised.

It's not always a fun way to work. It's really stressful and really intense. But this is because you'll have a more vertical role and you'll be closer to senior management. It can be really rewarding, provided you get along with your immediate boss. Nothing new there I guess :-)

You really need to put in at least 5 hours of real work per day dude. It's not so hard. 3 hours in the morning before lunch. Squeeze in a couple over the afternoon between emails.

Meetings are overrated anyway ;-) Just get comfortable with interrupting people.

As for multipliers, it's hard to say what is right for you and your type of work. Multiplying by 2 and increasing the order of magnitude (mentioned by a PP) might be necessary for highly experimental work or something, but if you're just building online shopping carts or something, you really ought to be able to estimate it more accurately than that.

Remember that using a multiplier is no silver bullet. You're still using a constant to try and adjust for a variable amount of hidden complexity. It just means that sometimes you wildly OVERestimate and so you get bragging rights for getting a project in "under time".

I guess I'm saying it merely helps maintain a thin veneer of professionalism. It doesn't make you right all the time, it makes you appear "inconsistently brilliant" (although the seeming brilliance is actually just good luck, not good management).
Jeff Send private email
Thursday, October 14, 2004
Your original estimate is probably not far off.  We use 6 hours of constuction per day.  To Jeff's point, the days are usually longer than 8 hours. 

In smaller companies you also tend to have more drags on your time that cannot be offset.  You may be able to blow off a meeting at SuperCorp, but you cannot blowoff the TPS reports that you need to produce daily at  There usually is no one else to do it.

Use 6 you will be close, use 4 and you will be safe assuming your estimates of the actual work are correct.
Thursday, October 14, 2004
I find that I get anywhere from 4-6 hours of development time each day.  I think that's slightly above average, but I couldn't tell you for sure.

I've been working to make my estimates granular enough to make them solid, I usually add an additional 113% (I like 13%) and submit those numbers to management.

In February, I was steadily -0/+25% off.
Through June, I was steadily -0/+15% off.
For the past three months, I have been within -5/+10%, so I think I may adjust my modifier to 120% and be done with it.

Rapid Development by McConnell gives all kinds of tips for developing solid estimation techniques.
KC Send private email
Thursday, October 14, 2004
Thanks for the input.  I did a bit more Googling and thinking and came up with the following formula:

y = (x*.8)*.75

'x' is the ideal hours in the week (40, 50, 80, whatever).  'y' is the available hours during which something productive gets done.  I took into account vacation/holiday/sick time, assume an allocation of 90% (meaning 90% of my time will be allocated to the project and 10% to other projects/tasks), and then assume 75% of the allocated time is productive time.  (Meaning time spent in front of the monitor coding/testing/debugging, not meetings, emails, installing software, etc.)

So it comes out to about 5-6 hours per day of useful work, which matches what you guys said.  Independent confirmation of results through different methodology :).

When I estimated effort, for each requirement I broke things down into chunks that I felt I could do in an "ideal" week (meaning 40 hours of real development), then multiplied that by 2 to factor in unit test, functional test, and debug time.  Add up the weeks to get a total in ideal 40-hour weeks, then use the multiplier to get actual calendar time.  Divide by the actual time-to-deadline and that gives me the number of developers required; or, divide by the number of developers available and that gives me the actual schedule.  Factor in another week up front for startup tasks, and another couple of weeks at the end for winding things down.

One thing I didn't factor in because of the small team size is team overhead.  Just using "gut feel" as my data, I would guess that for every doubling of team size after 5, add 2.5% to the schedule.  So for 6-10 add 2.5%, 11-20 add 5%, 21-40 add 7.5%, 41-80 add 10%.  That "feels" reasonable, but I don't have enough experience with truly large projects/teams to have high confidence in that.  Thoughts?
Should be working Send private email
Thursday, October 14, 2004
In order to make an accurate estimate, you need to know how long it took you to build something similar before.  That way, if you're going under/over, you can determine why based on last time's milestones.  Otherwise, you might as well just say 3 weeks/months (small/large project), I usually do because that's how long it takes me to do anything. Send private email
Thursday, October 14, 2004
When in testing/debugging phase, I used this on a project:

Print out entire list of outstanding bugs:
In a meeting, each one is assigned a duration of:
1) 1 hour
2) 1/2 day
3) full day
4) 3 days
Bella Send private email
Saturday, October 16, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz