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

31–40 of 100 posts

Re: Software Development Estimates: Where Do I Start?

#31

Post by jacques_chester »

wpietri wrote: post #30
jacques_chester wrote: post #15

Earlier quoted context omitted.

I agree that the estimation process needs to be tuned to fit the local context. There's no point building a 50-parameter statistical model for building a 3-page website. But likewise, SWAGs aren't appropriate for megaprojects. A more involved process is called for.

Or one can just not do megaprojects. An instructive example comes from one of Mary Poppendieck's books. 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. They were already building the lower floors before the upper floors were designed. One of the problems they faced was that nobody had designed an electrical sy…

> 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 amount of design, planning and construction simply to get to the point of turning it on.

> There is no central control, no central design, no plan.

You may have heard of the Internet Engineering Taskforce.

I agree that many systems have useful emergent properties born of simple rules; and where possible this should be used. Or rather, where such systems are found to already exist, they should be left largely alone.

However, sometimes solving a problem with interacting agents is more costly than simply picking the straight solution. If you can get an answer with a simple differential equation, then it's a waste of time to set up a particle swarm optimiser.

Re: Software Development Estimates: Where Do I Start?

#32

Post by jacques_chester »

wpietri wrote: post #27
jacques_chester wrote: post #25

Earlier quoted context omitted.

> There is a way to get a perfect estimate - and that is to build it and see how long it takes. The concept of a "perfect estimate" is tautological, isn't it? Estimates are by their definition uncertain statements.

I believe that's his point.

Then the larger point is that if estimates are always imperfect, we need to stop obsessing about their always being imperfect.

Re: Software Development Estimates: Where Do I Start?

#33

Post by jacques_chester »

wpietri wrote: post #26
jacques_chester wrote: post #16

> The gist of why estimates are hard: every new piece of software is a machine that has never been built before. I am tired of the argument that we unique snowflakes amongst all professions and that consequently we deserve special treatment. We aren't. All professions deal with uncertainty and most of them deal with it deliberately[1]. Throwing your hands in the air because a perfect prediction is impossible is just…

> I am tired of the argument that we unique snowflakes amongst all professions Aren't we, though? Zero marginal cost of production is at least very rare. It basically means that to the extent that our projects aren't novel, then we're wasting time duplicating something that ideally would have been copied from elsewhere. And that not even getting into the very high rate of change in tools, techniques, and materials (e…

> Aren't we, though? Zero marginal cost of production is at least very rare.

Every profession can come up with a comparable point of uniqueness. Perhaps I should have said "special snowflakes" instead of "unique snowflakes".

> It basically means that to the extent that our projects aren't novel, then we're wasting time duplicating something that ideally would have been copied from elsewhere.

This is a good argument. It reminds me of DeMarco's argument that as time goes on, software engineering becomes less and less about process, because anything that is repeatable will be automated. All that's left is the hard bits that can't be automated.

There is, however, an enormous amount of duplication in our industry. And even when we are adapting an existing system, we're still only rarely performing acts of genuine novelty. Carpenters produce many items, none of them quite identical, but they aren't inventing new methods of carpentry or entirely different kinds of furniture on every job.

> But at least on the projects I see, it's much more often a sign that it's an interesting problem.

I envy you.

Re: Software Development Estimates: Where Do I Start?

#34

Post by swanson »

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…

I agree with that estimates are largely about a [false] sense of control, but this is a tough sell when dealing any company with budgets and stakeholders that have to go ask their boss for a finite number of dollars to trade for software.

Often times, this is a one-time ask. You get money allocated once, so you better get enough to build the whole thing. You can't go back and say, "hey boss! look what we got with the first $10k, can I have $10k more?"

If you are a startup or dealing with a 4-figure project from a local business, then sure, you can probably skip estimates.

Re: Software Development Estimates: Where Do I Start?

#35

Post by xarien »

"The gist of why estimates are hard: every new piece of software is a machine that has never been built before."

This statement is simply not true. Every new piece of software can be broken down to pieces that are very similar to other software that had been done before. This is actually the secret to providing a good estimate.

What generally screws up estimates are complications that arise. Much of it actually has to do with pre-existing code as opposed to new code. If you were to build something from scratch and had a team of experienced engineers, I'd bet that you'd get a pretty damn accurate estimate.

Re: Software Development Estimates: Where Do I Start?

#36

Post by dreamfactory »

xarien wrote: post #35

"The gist of why estimates are hard: every new piece of software is a machine that has never been built before." This statement is simply not true. Every new piece of software can be broken down to pieces that are very similar to other software that had been done before. This is actually the secret to providing a good estimate. What generally screws up estimates are complications that arise. Much of it actually has t…

Disagree entirely. If "Every new piece of software can be broken down to pieces that are very similar to other software that had been done before", you are talking about assembling library components, not programming (though as you say even that often comes with its own unforeseeable difficulties).

This is the fundamental paradox of software development estimation (and separate to the uncertainty of external forces): when you try to estimate development you are estimating design of something that has never been made before. If you aren't, you should probably be buying a product instead of building. It's a fool's errand basically.

Re: Software Development Estimates: Where Do I Start?

#37

Post by dreamfactory »

jacques_chester wrote: post #16

> The gist of why estimates are hard: every new piece of software is a machine that has never been built before. I am tired of the argument that we unique snowflakes amongst all professions and that consequently we deserve special treatment. We aren't. All professions deal with uncertainty and most of them deal with it deliberately[1]. Throwing your hands in the air because a perfect prediction is impossible is just…

I have heard that it is actually just as bad on large construction projects and that the trend there is to move towards more lean approaches.

Re: Software Development Estimates: Where Do I Start?

#38

Post by robinhoode »

swanson wrote: post #34
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…

I agree with that estimates are largely about a [false] sense of control, but this is a tough sell when dealing any company with budgets and stakeholders that have to go ask their boss for a finite number of dollars to trade for software. Often times, this is a one-time ask. You get money allocated once, so you better get enough to build the whole thing. You can't go back and say, "hey boss! look what we got with the…

> Often times, this is a one-time ask. You get money allocated once, so you better get enough to build the whole thing. You can't go back and say, "hey boss! look what we got with the first $10k, can I have $10k more?"

This is an area where software engineers who've made serious profits and turn around to become investors have an edge over traditional that do not understand the levels of risk involved with large software projects.

Explaining the granularity in the types of risk that are involved is complicated to people that expect to write a check once and have a finished product come out of it.

Re: Software Development Estimates: Where Do I Start?

#39

Post by dreamfactory »

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.
Post reply on HN