Comments on: I can have that for you next week http://www.starchamber.com/2005/02/i-can-have-that-for-you-next-week.html Ned Gulley's Blog. Resident buzzwords: synthetic biology, ambient displays, swarm robotics, wise crowds. Fri, 21 Nov 2008 21:29:03 +0000 http://wordpress.org/?v=2.6 By: aslam http://www.starchamber.com/2005/02/i-can-have-that-for-you-next-week.html#comment-638 aslam Wed, 16 Mar 2005 06:43:38 +0000 http://starchamber.com/?p=1024#comment-638 Then there are those of us whose time estimates depend on whether they've conceptually solved a problem. As long as the solution remains elusive, there can be no estimate but, once it gels in the mind, the project is all but complete. Then there are those of us whose time estimates depend on whether they’ve conceptually solved a problem. As long as the solution remains elusive, there can be no estimate but, once it gels in the mind, the project is all but complete.

]]> By: Lynn http://www.starchamber.com/2005/02/i-can-have-that-for-you-next-week.html#comment-637 Lynn Tue, 22 Feb 2005 15:17:47 +0000 http://starchamber.com/?p=1024#comment-637 I asked Melissa how she always gets her scheduling so accurate, and it seems she used to keep painful track of how long it took to do everything on another project -- and learned from that. Learning this type of estimation skill requires that you are capable of decomposing a new task into similar chunks that you have already experienced in the past, and then applying the rules internalized from the past; and that you know how much better or worse you will be at doing the same or similar thing over again in a new context. I'm fascinated by this problem in general, but especially in software, where there are many moving parts to be integrated. Project management is the hardest discipline of all, I think (in terms of the problems to be solved). There's another factor, of course, behind the time estimate problem in software-- they aren't always realistic, even knowingly, because of various meta-reasons: overpromising gets you the cool project or VC funding, and ridiculous over-estimates of worktime might be delivered by someone not wanting to touch a project with a ten foot pole, so they're meant to discourage. We (I) sometimes did this in France when consulting, and I've seen engineers do it as a passive aggressive strategy with marketing requests. I asked Melissa how she always gets her scheduling so accurate, and it seems she used to keep painful track of how long it took to do everything on another project — and learned from that. Learning this type of estimation skill requires that you are capable of decomposing a new task into similar chunks that you have already experienced in the past, and then applying the rules internalized from the past; and that you know how much better or worse you will be at doing the same or similar thing over again in a new context. I’m fascinated by this problem in general, but especially in software, where there are many moving parts to be integrated. Project management is the hardest discipline of all, I think (in terms of the problems to be solved).

There’s another factor, of course, behind the time estimate problem in software– they aren’t always realistic, even knowingly, because of various meta-reasons: overpromising gets you the cool project or VC funding, and ridiculous over-estimates of worktime might be delivered by someone not wanting to touch a project with a ten foot pole, so they’re meant to discourage. We (I) sometimes did this in France when consulting, and I’ve seen engineers do it as a passive aggressive strategy with marketing requests.

]]>