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.
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot
The Old Forum
Albert D. Kallal
I'm currently reading the Joel on Software Book. In chapter 9: "Painless software schedules", I have two issues.
1) Joel says that you have to make estimations in hours, preferably 2-16 hours. As he concludes, this implies that one has to figure out exactly what steps are to be taken, e.g. "Write subroutine foo. Create dialog such and such. Read the wawa file.” I.e. we have to do the design!
I think it would be great if this were how it all works in the real world in which I happen to live in. However, often the situation is that the manager comes down to me and says, "yippee, we have this new fancy prospect which is supposed to do this and that and I wonder how long it will take."
If I say, "yes you can have an estimate, but first I'll have to design the damn thing", he would, on his happy day, go to someone else...
2) Joel says that the ship data is calculated as "adding up the remaining time column and dividing by 40". Hmmm. During my eleven years of programming I have just had a couple of effective 40-hour weeks. (And I consider myself to be an effective developer.) Time is spent on meetings, coffee breaks, chatting with the colleagues, and many other small thingies that inevitable adds up to something that cannot be disregarded. So, if we want a realistic ship date we have to divide with something else than 40. Maybe 31,4159?
What are your thoughts on these "issues"?
1) Factor Vacation, Sick Days, and Holidays into the schedule. Same deal for Administrivia - figure out the % of your time it is, and add that in. You can lump all that together into overhead.
Then add in risk. I usually charge between 10 nand 40% for risk, but lately I've had projects that are less risky.
So you might have:
5 Weeks + 25% overhead + 25% risk = 7.5 weeks.
Also, In my experience, it's totally reasonable to say "I don't know. I can get back to you (tomorrow or by the end of the week if it's big")
If your managers don't let you say that, that's telling you something.
I'd recommend "Death March" by Yourdon ... It has chapters on how to deal with gaming project estimating ...
Monday, October 11, 2004
On 1, you don't need to completely do the design. You just have to think about it. If you want to add a new user role to a web app (an example from last week), you don't think about "I'll need column X, Y, and Z in the database. I'll need new class A, with exactly this set of fields...". YOu think, "I'll need one new database table, one new class, the unit tests associated with that class, I'll need about 3 new SQL queries of moderate complexity".
Of course, that level of estimating is possible because I'm doing short estimates. We're an XP shop, so we don't estimate too far ahead, maybe a couple of weeks worth of work. That's one of the things I like about XP. Easy to estimate and plan.
As for point 2, for what it's worth, my manager plans on a 35 hour work week. That turns out to be pretty accurate. Of course, our 35 hour weeks *include* meeting time and such. We (a contractor) have a default estimate of 5% for 'project management' tasks (developer meetings, doing estimates, etc.), and 5% for 'client communication' (talking with the client). This turns out to work fairly well. But again, we're estimate only a couple weeks worth of work at a time.
Extreme Programming has a concept that programmer's NEVER produce 40 hours of work in 40 hours. So, they have an 'effectiveness' multiplier -- typically 2.5, I believe.
Thus, if you have 40 hours of work, it will take 100 'clock' hours to implement it, with a 2.5 multiplier. Note the 2.5 factor depends not only on programmer productiveness, but also the environment he works in -- freedom from interruptions, access to resources (books) equipment and tools.
Second -- Yes, I usually have to do a quick 'straw-man' design to develop reasonably accurate hour predictions. 'Quick' here is like 4 hours.
This is MUCH better than saying "I think that will take two weeks" off the cuff. Unfortunately, the hour predictions then take a life of their own, no matter HOW the underlying project changes (making the Strawman design more and more obsolete). If you are very good (and lucky if your Manager will listen), you will adapt the Strawman design each time the project changes, and use that for updating the project hour plan.
Monday, October 11, 2004
Hmm. Joel does write about how difficult it is to get going sometimes, so using hourly increments does seem a little strange.
My personal preference is to use 4 hour increments. I.e. half days. So I can say "two tasks today" or "one task today" or "this task lasts 2 or 3 days." That's about as granular as I want to get.
Now, what happens in reality is something completely different.
Also, I started from the simplest, like Painless Software Schedules in Excel and started to think to myself "gee, wouldn't it be great if it had weekends and holidays and dependancies" and where my thinking ended up was MS Project. Just about every time I said "I need to add this..." I also said "...and MS Project does that."
Monday, October 11, 2004
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz