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

41–50 of 100 posts

Re: Software Development Estimates: Where Do I Start?

#41

Post by biot »

An analogy I like to use: "Here's a book of sudoku / crossword puzzles. How long would it take you to solve all of them?"

Estimating this is similar to estimating a software system. You've seen puzzles like them before, but you don't know the difficulty level of each or which ones have tricky clues that cause you to rack your brain trying to find the solution. It also nicely illustrates the 10x effect: some puzzle solvers breeze through them while others take forever.

If you could break a software system down into a rigorous formal specification that could be precisely estimated, it would be possible to use that specification to build it automatically. Then that shifts the estimation up the ladder of abstraction to one where you estimate the time to create the rigorous formal specification.

Re: Software Development Estimates: Where Do I Start?

#42

Post by redact207 »

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…

In the enterprise I work in, people need estimates in order to manage resourcing - which is not something unique just to the software industry.

We always have a prioritised list of projects but only a limited number of developers, so for us estimation lets us know when a developer is available to work on the next project.

Estimation is important and before any project is accepted we go through maybe a day or two working out the main application structure, breaking it down and providing rough, high-level efforts. Then we factor in the usual holidays, risk buffer (illness, estimation uncertainty), rigging, testing, release etc. Once the project's accepted then a more accurate plan is delivered after we have a design and task list ready.

The main thing I've learnt is people are far more willing to accept over-estimated plans at the beginning rather than extend a project that's run overtime.

Re: Software Development Estimates: Where Do I Start?

#43

Post by contingencies »

jacques_chester wrote: post #21
contingencies wrote: post #19

Earlier quoted context omitted.

If you go into a gymnastics club and you can't do a backflip, that doesn't mean backflips are impossible in principle. It means you can't do it. Estimation is a skill too. Cute metaphor, but I'm calling bullshit. Fundamentally, if something is completely new, sometimes nobody knows if it's even possible. Granted, that's almost never the case for software algorithms. But holistically speaking, in real software-centric…

The Manhattan Project was authorised because it could be shown that an atomic weapon was possible. Nobody had any idea how to build one or how it would work -- they just knew that a calculation based on runaway radioactive breakdown implied a large release of energy. But how often are we doing a Manhattan Project, where research is a major initial output? Not very often at all. Throwing out estimation for all project…

All fair enough.

Perhaps what we can take from this constructively is that you could consider making the USP for your estimation tool more of a focus on uncertainty/overall project risk modelling more so than straight up timeframes, which we all know are pie-in-the-sky at the best of times and not really as critical as outright SPOFs/third party deps.

Re: Software Development Estimates: Where Do I Start?

#44

Post by jacques_chester »

contingencies wrote: post #43
jacques_chester wrote: post #21

Earlier quoted context omitted.

The Manhattan Project was authorised because it could be shown that an atomic weapon was possible. Nobody had any idea how to build one or how it would work -- they just knew that a calculation based on runaway radioactive breakdown implied a large release of energy. But how often are we doing a Manhattan Project, where research is a major initial output? Not very often at all. Throwing out estimation for all project…

All fair enough. Perhaps what we can take from this constructively is that you could consider making the USP for your estimation tool more of a focus on uncertainty/overall project risk modelling more so than straight up timeframes, which we all know are pie-in-the-sky at the best of times and not really as critical as outright SPOFs/third party deps.

I'm taking the PERT 3-point estimation technique as my starting point (decompose the project, for each component, give best/likely/worst, roll up results with a formula). It bakes uncertainty and probabilities directly into the outcomes.

I'd encourage users to look at estimating project size first and then deriving effort, schedule and cost. But I won't constrain them to it.

Re: Software Development Estimates: Where Do I Start?

#45

Post by wpietri »

jacques_chester wrote: post #31
wpietri wrote: post #30

Earlier quoted context omitted.

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…

> 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.

Yes, I have. 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.

Re: Software Development Estimates: Where Do I Start?

#46

Post by wpietri »

redact207 wrote: post #42
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…

In the enterprise I work in, people need estimates in order to manage resourcing - which is not something unique just to the software industry. We always have a prioritised list of projects but only a limited number of developers, so for us estimation lets us know when a developer is available to work on the next project. Estimation is important and before any project is accepted we go through maybe a day or two work…

Resourcing and estimating against plans is one approach, but it's not the only one. You can also use a flow-based approach. Basically, you have teams with queues; whenever a team is out of work, they pop something from the queue and work on it until complete. Or, if the organization is more subtle, you release early and often, ending a project when it looks like the team can be more usefully deployed elsewhere.

Mary and Tom Poppendieck cover this approach a fair bit in their books.

Re: Software Development Estimates: Where Do I Start?

#47

Post by wpietri »

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…

Sure, but that's an artifact of traditional budgeting. In the Lean world (as in Lean Manufacturing), traditional budgeting is considered a dangerous and misleading activity.

Another way to work it is to have a backlog of valuable things to do that get handed out to teams. When somebody needs something to do, you pick the highest-ROI project from the backlog and give it to them.

In that context, detailed specs and careful estimates generally turn out to be wasteful. If you're trying to pick projects by expected ROI, then making the software estimate more precise than the (generally handwavey) business value estimate is pointless.

Re: Software Development Estimates: Where Do I Start?

#48

Post by alok-g »

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

What is not explicitly said here is that a good developer needs to know what would be a "new" piece of software. He should be at least vaguely aware of what has been built already, what is within the reach of the state of the art, etc. And just like in the stock market, it is impossibly hard to know all the needed information to come up with wise judgement, complicating the estimation process even more. Yet, this is an essential piece in estimation anyways. Just for example, for some projects you may simply declare them to be beyond the state of the art.

Re: Software Development Estimates: Where Do I Start?

#49

Post by wpietri »

jacques_chester wrote: post #33
wpietri wrote: post #26

Earlier quoted context omitted.

> 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.…

> Every profession can come up with a comparable point of uniqueness.

Not in ways that have such dramatic effects on predictability of costs.

> There is, however, an enormous amount of duplication in our industry.

Sure, but if we're going to put our attention somewhere, I'd rather we work on eliminating that waste, rather than standardizing the waste so that we can better estimate the cost of doing work we didn't really need to do.

Re: Software Development Estimates: Where Do I Start?

#50

Post by wpietri »

brudgers wrote: post #17

Knowing a bit about estimating construction, and a bit more about the estimating of design which is more akin to software, there's more to the ability to execute according to a time table than the author gives credit...and the fact that the process can be separated between design and construction gives a clue. Mature processes for delivering construction start with a budget and something called a program - an archite…

The software process can not actually be separated into design and construction. Software is a 100% design activity. Construction is what our compilers and installers do. Projects that appear otherwise have created artificial barriers to prevent certain kinds of design at certain times.

You're also missing that repeatability in software is a sign of waste. If developers are doing things that are truly well-understood and predictable, then they're doing something wrong. They should download a library or extract a framework, automate the predictable parts, and shift their attention to something worthwhile.

Post reply on HN