4 ms·
The thing that annoys me most about project estimation is when the micro-managing types don't let you even look at the problem space first, an instant answer is
by Theodores 11y ago
The thing that annoys me most about project estimation is when the micro-managing types don't let you even look at the problem space first, an instant answer is expected. Of course the figure plucked out the air could be 'x days' with 'x' being greater than the time one expects internally so backside is covered, yet that is not really a true answer.
At the moment I am putting together a 'simple' feature on a website, where I have been able to explore the problem space first. For the $content there actually needs to be half a dozen date fields that were not in the original brief, I doubt I would have discovered this had I not rolled a little bit of code first and explored 'prior art' in the area.
I need to put together a semi-working prototype to discover such things - particularly when UX is involved. Yet, far too often, the opportunity to do actual preliminary dev work is denied by those that 'know best', preferring a spec. in a Word document (or something else equally 1990's) instead of a rough working prototype in code (with back-of-envelope sketch).
My current feature-being-added will need to be re-factored at some stage, once users have started using it and problems/features overlooked in the original brief catered for. It is not as if the users of my new feature will know that 'actually they wanted it to work this way' until they have something to see. So why we have these silly cast-in-stone processes I do not know.
I also must say that I find the metaphor of painting a room is quite a poor one, I would not need to paint 'an alcove first' to get a handle on how long the whole room would take.
- Ensorceled 11y agoActually, the metaphor is pretty good, except they missed a key change: in real life if the "test painting" shows you need to "prime first" you now have no idea how long it will take without starting the estimation process all over again. So, in real life, paint the room is "2 days or, if the test painting goes badly on day one, I'm not sure and won't know until the end of day 1". And people don't like those kinds of estimates.
- crpatino 11y agoIf that's the case, you assume priming will be needed in your original estimation, then go do the test anyways, and at the end of day one you will look like a hero when you say "hey guys, I think we can get away with cutting priming from the plan, we just saved $abc from the budget and xyz days".
- LoSboccacc 11y ago> don't let you even look at the problem space first this is the core of the issue. when one has the time to break down all unknowns and discover them, estimate are quite spot on. but who want to pay for the estimate? so we are left trying to guess what time a particular unknown is going to take to solve. the good metaphor here is asking how much time it will take to solve a puzzle magazine, from cover to cover by looking at the title.
- GFischer 11y agoThe point you're making is exemplified in this article which makes an analogy to a hike from San Francisco to Los Angeles: http://www.michaelrwolfe.com/2013/10/19/50/ http://www.michaelrwolfe.com/2013/10/19/50/ from https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3 https://www.quora.com/Why-are-software-development-task-esti...
- GFischer 11y agoSomething I took from several articles is, most managers don't really need an estimate - what they need is a commitment, and/or a budget (and the estimate is an input to generate said commitment or budget). https://www.mountaingoatsoftware.com/blog/separate-estimating-from-committing https://www.mountaingoatsoftware.com/blog/separate-estimatin... https://hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate https://hbr.org/2014/12/your-agile-project-needs-a-budget-no...