DISQUS

Tim · 1 year ago

@Jake, Nice post - estimation becomes laughable when all the manager is interested in is that if you estimated 4 weeks for a project and you're a week in then you should be at 25% complete! Software dev is a little 'hockey stickish' - managers need to remember that.

@Dave - grey hair!?! ... I wish! When I arrived in the US in 99 I had a full head of it. Those that know me, will know that 'a bit thin on top' is a gross exaggeration :0)
Im not blaming s/w development - I blame my kids :0)

davidhaimes · 1 year ago

@Tim - now you mention it, s/w is a walk in the park compared to kids

Jake · 1 year ago

Yeah, project planning is so hard b/c it attempts to apply hard and fast dates to work that's highly variable, even hour-to-hour for the same person on the same project.

davidhaimes · 1 year ago

The way discussions often go, is I explain what needs to be done with some squiggles on a white board, a lot of talking and a bit of arm waving. Then I ask the engineer
"How long do you think that would take?"
They respond
"What's the deadline?"
"I just want an idea how much work you think it is"
"Well it depends. What deadline do I have?"
"Tomorrow"
"Tomorrow! It'll take me at least two weeks"
"Finally, thanks"

Jake · 1 year ago

Yeah, this is a problem with deadline-based estimating. If only we could build s/w in a vacuum w/o any deadlines. I'll bet that would rock.

Jake · 1 year ago

Totally, this is estimation by bullying with a date. Not sure why this happens so much, but it's very common.

gary · 1 year ago

The bit that gets me is whether the manager wants an estimate of effort time, or calendar time. It may take a week of coding to do a module, but you have to wait for an API spec to write one call, or for a db refresh to run a test, so there's two or three weeks between start and end.
Any estimate that doesn't come in a format like "About x hours for the first week, then y for the next two and another z at the end for sign-off, but only after Fred is back" is too simplistic

davidhaimes · 1 year ago

I am happy to get an estimate of x hours to design, code and unit test. As a project manager my job is to help put all the other moving parts into place, dependencies, documentation, QA, performance testing, vacations etc.

Jake · 1 year ago

You're right. That doesn't make it easy though.

Jake · 1 year ago

You sound like a very scientific estimator.

You and Meg both bring up a reason that development is hard to estimate; there are inevitably unforeseen and unscoped moving parts that frequently are forgotten or can't be estimated anyway.

Another reason why project management is maddening.

megbear · 1 year ago

Jake, you come close to nailing it for me with this one although I tend to see a few more layers between. One thing I find a lot is not just the estimate time but also the comprehension of "what" the estimate should include. Developers I work with are quick to think of design/code/unit test but what about UE polish? Performance testing? Integration testing? ADA compliance testing? automation? and so on. The "oh, I wasn't including that" is where the biggest risks come into the picture for me. Probably a sign of the size projects I tend to be involved with but all those "little things" can add up to be a project killer if you are not clear on the "what"

Jake · 1 year ago

Good point. From my days in apps development, mandates moved too fast for training to keep up with them, e.g. Forms to OAF impacted estimates across the board, design/code/test/doc all that.

Don't ever let anyone tell you s/w is easy.

davidhaimes · 1 year ago

writing software is easy, building a robust, performant, scalable, deployable, ADA compliant, platform independent, patchable, upgradeable and commercially viable ERP suite is tough. That's why my hair is turning gray.

Jake · 1 year ago

Your hair isn't gray, and s/w is hard. Everyone should know that by now.

pgkiran · 1 year ago

5-6 years back I had a manager, who used to ask me for estimates with break down and when he builds the schedule he used to simple double the estimates and publish it up. It kind of made sense in a way with all the little little things that pop up we could never meet the dates and it also used to give us time to learn, find new ways to things if we do finish things on time. As a dev manager now I try to follow those principles however sometimes we try to break the complexity using Agile development methodologies,twice a month deliverables with a complete dev,qe, integration and product management validaton cycles. For sometime I also used LiquidPlanner to come with estimates with some fluidity built in, I blogged little bit about it at http://www.appme.net/2008/09/09/liquidplanner-p...

Jake · 1 year ago

Doubling the estimate is a classic tactic, but it underlines the fact that the estimate is wrong from the get-go. How great would it be if the estimates were right?

Whenever possible, I prefer to ask the developers to commit to a number and negotiate down to where we're both comfortable. This means they own the dates as much as management does. Classic wisdom from a box whose name escapes me right now.