Live data from Hacker News

Software Development Estimates: Where Do I Start?

diegobasch.com

81–90 of 100 posts

Re: Software Development Estimates: Where Do I Start?

#81
post #41

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

Good analogy. But I would add "this book and the next one that I create" and "you can have help from whoever happens to be with you"

In the best case there is still a little "unknown unknown" about both the scope and team. The project manager can tighten things but you can never completely get rid of it.

Re: Software Development Estimates: Where Do I Start?

#83
post #41

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

Suppose you're asked to estimate a single sudoku problem. That's basically impossible, because n=1. In small samples from a large population, variation is enormous. But what if I ask you to estimate the time for 100 sudoku problems? For 1000? What if, after 2 years of solving sudoku problems full time I ask you for your estimate? What if I develop simple statistical models based on the number of squares that are alre…

> What if I develop simple statistical models based on the number of squares that are already filled in?

What if you were unable to? NP-hard problems are weird like that. What if the underlying statistical distribution had random variance or some other strange features that make traditional statistical models useless?

Maybe the issue is that we're trying to use intuitions developed with everyday problems that are essentially linear ("mow the lawn", "drive to the store") in places where they're not appropriate. Unlike usual everyday tasks, NP-hard problems (such as Sudoku or coding) have no known "royal road" - sometimes you just have to try all possible solutions.

Re: Software Development Estimates: Where Do I Start?

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

I think that it is on a spectrum from sysadmin work to software development work. The closer something is to engineering doctrine, the closer it is to systems administration. If company A wants a Linux VM with Apache and some static pages, there is some per-customer work versus company B, but it is very easily estimated. All of the differentiation lies in cost or customer service at that point. And there is a lot of corporate programming that gets close to that, and is more estimatable than other stuff.

Re: Software Development Estimates: Where Do I Start?

#85
post #47

Earlier quoted context omitted.

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

> you pick the highest-ROI project from the backlog How do you calculate the return on investment without estimating the investment?

You don't have to know the ROI value of each project, just compare their relative sizes to select the best from the set of projects with the highest profit ranking.

This assumes, though, that the best of the projects is worth building in the first place.

Re: Software Development Estimates: Where Do I Start?

#86
post #47

Earlier quoted context omitted.

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

> you pick the highest-ROI project from the backlog How do you calculate the return on investment without estimating the investment?

Well, one option is time-boxing. You say, "We'll put a team on this for up to two months: they get done what they get done." It's a fixed investment; it's up to the business stakeholders to judge what kind of return they can get out of that.

But in the this context, by "estimation" I mean "formal estimation". Having developers glance at something and ballpark it is basically a zero-cost activity. As long as that I number has about the same error bars as your R number, then it's perfectly fine for ROI. Especially given typical requirements volatility, and a project approach that sharpens ROI estimates as you go.

Re: Software Development Estimates: Where Do I Start?

#87
post #65
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?"

Sure. But instead of estimation, one can take a risk-management approach to that.

For example, I'll get people to talk about everything they want. I'll put each thing on an index card. I'll have them lay the index cards out in order of importance (or ROI) on a big table. Then I'll ask: "Draw a line where, if you didn't get that far, you'd just bow out of the conference."

Typically, that line is pretty early, 10-30% of what people would really like to have by the date. So then you take the backlog, make sure it isn't too lumpy, and start working. Just by measuring cards/week, you can pretty quickly know whether you'll hit the date. And typically, the team will have something shippable well before the date.

The question then becomes: when is the ROI for the next week's work going to be lower than the ROI for something else we might do? And that question ends up being pretty easy, because you've pushed the decision off until you have a lot more data.

Re: Software Development Estimates: Where Do I Start?

#88
post #49

Earlier quoted context omitted.

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

Your last remark is true, but a bit falsely dichotomous. The choice isn't between perfect estimates and zero wastage. In practice all projects lie on a continuum between totally novel and pointless duplication. Within that continuum we can draft estimates of varying accuracy and I don't see a reason why we shouldn't.

The amount of time we get is fixed. Estimation is, from the Lean persepective, muda (normally translated as waste). If I can be spending that time instead on an activity that reduces the waste of duplication, I'd rather do that.

I should be clear that I'm not totally opposed to doing estimates. I've done a lot of them, I'm good at it, and there are circumstances where I would do it again. Some waste is temporarily necessary.

What I'm pushing back against here is the common assumption (which maybe you don't have) that estimates are generally a good thing to do, or, often, the only way to do things.

Re: Software Development Estimates: Where Do I Start?

#89
post #45

Earlier quoted context omitted.

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

I did not say that the Internet was not designed. But I'm glad to say that now. Specifically, it was not designed in the sense that megaprojects requiring planning and estimation are designed. My point there is that people just assume that big achievements require big plans, but that is demonstrably false.

I do agree, as a long-time reader of RFCs, that some of the protocols were designed, sort of. But if you read more deeply, you'll see that they were just as much evolved. And, that they were never imposed through a central control structure. It's no accident that the foundational documents of the Internet are all Requests For Comment. An instructional contrast is the OSI protocol suite, a top-down alternative to the Internet. Now dead, of course.

I agree that some projects can be estimated. I'm saying a lot of them shouldn't be, because there are more effective ways to get results.

You can read more about that, and about the 3M example, in Mary Poppendieck's books. I think the specific one I have in mind Leading Lean Software Development.

Re: Software Development Estimates: Where Do I Start?

#90
post #83

Earlier quoted context omitted.

Suppose you're asked to estimate a single sudoku problem. That's basically impossible, because n=1. In small samples from a large population, variation is enormous. But what if I ask you to estimate the time for 100 sudoku problems? For 1000? What if, after 2 years of solving sudoku problems full time I ask you for your estimate? What if I develop simple statistical models based on the number of squares that are alre…

> What if I develop simple statistical models based on the number of squares that are already filled in? What if you were unable to? NP-hard problems are weird like that. What if the underlying statistical distribution had random variance or some other strange features that make traditional statistical models useless? Maybe the issue is that we're trying to use intuitions developed with everyday problems that are ess…

NP-hard problems often have "good enough" solutions that don't take heat-death time to solve. Consider the TSP. You can wait until the last proton decays and tie up all matter and energy in the universe.

Or you can use an ant colony optimiser and accept that you will probably only come to within a few percent of the best possible solution. Oh noes!

And so it is with estimation. We can build an ever-more-elaborate estimate that will consecutively shave fractions of a percentage point of precision and accuracy. Or we can accept that they are estimates, that they are meant to be imprecise and that accuracy is a range, not a number.

Post reply on HN