Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Development Estimates: Where Do I Start?

diegobasch.com

Post reply on HN
Print view View original

61–70 of 100 posts

Re: Software Development Estimates: Where Do I Start?

#61

Post by jacques_chester »

wpietri wrote: post #45
jacques_chester wrote: post #31

Earlier quoted context omitted.

> The Empire State Building was never planned and estimated in the traditional sense. They picked a deadline and used a flow-based approach to make it happen. Industrial projects tend to have operability thresholds; that is, they're not composed of relatively homogenous outputs. Each floor of a skyscraper is similar to the other floors. But a petrochemical process plant can't be built in slices; you have to a minimum…

> But a petrochemical process plant can't be built in slices; you have to a minimum amount of design, planning and construction simply to get to the point of turning it on. Poppendieck also gives examples of using similar processes for 3M's manufacturing plants. Regardless, I think drawing physical analogies for software is risky; software is infinitely soft. > You may have heard of the Internet Engineering Taskforce…

> Regardless, I think drawing physical analogies for software is risky; software is infinitely soft.

Sure, but I also think that this doesn't imply infinite intractability for actual problems. That a problem is NP-hard, for example, doesn't mean we can't find quite-good solutions to it that have business value.

> And either you don't know what they do or you're drawing a false analogy between traditional planning processes and what the IETF does.

You said that the internet was not designed. The protocols didn't evolve without supervision. Every part of them was designed for a purpose.

The question here is whether you think I'm saying "complex systems with emergent properties can be estimated or planned". That's not what I'm saying. I'm saying that not all problems are complex and not all problem systems have emergent properties. Many problems are eminently suitable for estimation.

It does not follow that since in some cases estimation is going to provide very little net business value that we ought to do away with it in all cases.

Could you elaborate on the 3M example, or provide a link? I'd like to read more.

Re: Software Development Estimates: Where Do I Start?

#63

Post by cs02rm0 »

swanson wrote: post #2

Most people would agree that practice makes perfect, right? I think a big issue with software estimation is that it is hard to get practice. I'd done full project estimates for 4-6 projects in 3 years of working professionally. Compared to the amount of practice I have writing code, this is nothing. How can I ever hope to get good at something if I only do it once every 3-6 months and it might take 2 years to get fee…

> Most people would agree that practice makes perfect, right?

Probably, if you're building the same software system, over and over. If you're building a different one, no I shouldn't think it does.

Re: Software Development Estimates: Where Do I Start?

#64

Post by rgrieselhuber »

wpietri wrote: post #28

My main trick these days for this problem is to discourage estimation by pointing out the costs of it and putting the burden on the requesters. One great way to do that is to release early and often, allowing stakeholders to change plans in response to what they've learned. Instead of doing the work of (re-)estimating a bunch of stuff every week, their focus on what's actually going on lets them stop obsessing about…

It's not only about control and risk management. In external-facing products, other departments (sales, marketing) need time in order to prepare materials, etc. in order to plan their own projects. Telling these groups "it'll be ready when it's ready" doesn't really help them.

Re: Software Development Estimates: Where Do I Start?

#65

Post by rahoulb »

wpietri wrote: post #28

My main trick these days for this problem is to discourage estimation by pointing out the costs of it and putting the burden on the requesters. One great way to do that is to release early and often, allowing stakeholders to change plans in response to what they've learned. Instead of doing the work of (re-)estimating a bunch of stuff every week, their focus on what's actually going on lets them stop obsessing about…

That does depend upon your circumstances however.

Often there are hard dates that can't be moved - because they are external to your organisation; the autumn TV schedule, or launching at a particular conference are two that have hit me in the past.

Of course that does make the estimation a slightly different process - not "when will this be done" but "can you be ready before this date?"

Re: Software Development Estimates: Where Do I Start?

#66

Post by arethuza »

yannis wrote: post #11
philbarr wrote: post #6

One thing my Dad always told me about software estimates: "Take the estimate, double it, and increase the time unit by one. So if they tell you it's a couple of days effort, that's really four weeks..."

Use the pi rule. Multiply the estimated duration by pi. Works for many other things too, besides software.

Multiplying by a value between 3 to 4 seems pretty common - the explanation I've heard being:

- One to work out what you should be building ("I have to tel you what I want? I might as well build it myself")

- One to build it

- One to get in working in the required way (allowing for "That may be what I asked for, but it's not what I want")

And a bit more for contingency...

NB The above approach is based on an assumption that the real difficulties come from working out what to build - technical risks are generally easier to address (prototypes etc.).

Re: Software Development Estimates: Where Do I Start?

#67

Post by DanielBMarkham »

dreamfactory wrote: post #39
DanielBMarkham wrote: post #8

"...The gist of why estimates are hard: every new piece of software is a machine that has never been built before..." Yes, and that's why a lightweight, repeatable estimation process beats every other way of doing it. As you continue to estimate, you create and refine a mental model of the project's complexity. For some projects, you're able to create a mental model that has high fidelity quite easily. For others, it…

Interestingly, Thoughtworks have observed that over a project they get the same consistency simply counting number of tasks as counting effort estimates for those tasks. The key for project management is therefore to focus on maintaining a backlog of manageable tasks and throughput, not in estimating them individually.

We're finding this out in a lot of places. The key issue is variability. Larger sample sizes usually lead to less variability, which means flow-based systems will hold up better.

If you've broken your work out into tasks, instead of stories, presumably you have a lot of them, and they're mostly the same size over a large set. So sure, should work fine.

If, however, you have a small number of highly-variable chunks of work, then flow-based systems fail. It all depends on the nature of the item pool.

Re: Software Development Estimates: Where Do I Start?

#68

Post by louthy »

zackbloom wrote: post #4

My key advice is to not pay attention to the minutia of the task, if you do you'll always underestimate. A better method is to forget the specifics and ask yourself 'If a buddy told me he was doing this, how long would I guess it would take?'. We have more experience hearing about projects and how long they took then we do really estimating the duration of creative tasks by reduction.

This is finger-in-the-air approach, which seems doomed to fail. For a start, it relies on your buddy having exactly the same career experience as you, and any new project being an almost exact match to previous projects you have worked on.

It doesn't take into account the unknowns, and doesn't break the task down into components that you could at least attempt to quantify.

Personally I go through a short mental breakdown of the project, trying to partition it in my mind into smaller jobs. Based on my years of experience I will then have a gut feeling for certain aspects of the project.

If any job is more than 3 days long, then I try to break it down further.

If I can't mentally break it down, then I need to spend some time researching why that is (investigate the unknowns).

Once everything has been broken down, and I have reduced the unknowns as much as possible I add contingency. Anything that I feel has the potential to be problematic I will add more contingency to, or add additional research time.

Re: Software Development Estimates: Where Do I Start?

#69

Post by sateesh »

rahoulb wrote: post #65
wpietri wrote: post #28

My main trick these days for this problem is to discourage estimation by pointing out the costs of it and putting the burden on the requesters. One great way to do that is to release early and often, allowing stakeholders to change plans in response to what they've learned. Instead of doing the work of (re-)estimating a bunch of stuff every week, their focus on what's actually going on lets them stop obsessing about…

That does depend upon your circumstances however. Often there are hard dates that can't be moved - because they are external to your organisation; the autumn TV schedule, or launching at a particular conference are two that have hit me in the past. Of course that does make the estimation a slightly different process - not "when will this be done" but "can you be ready before this date?"

but "can you be ready before this date?

IMHO right answer to this is, Yes we can be ready but we might have to scale down on some of the features. But in reality most of the time only the initial 'Yes' part is heard with the caveats being ignored. As mentioned many a times it is "quality, features, schedule" and one can pick only two.

Re: Software Development Estimates: Where Do I Start?

#70

Post by annnnd »

Not sure where I first heard this (and it applies more to single developers), but I find this very true: when estimating the time needed to perform something, try imagining how much time ANOTHER person would need. In general we underestimate the amount of work when thinking in first person; we are much more accurate when assessing the ability of others.
Post reply on HN