Live data from Hacker News

What We Do and Don't Know about Software Development Effort Estimation

infoq.com

41–49 of 49 posts

Re: What We Do and Don't Know about Software Development Effort Estimation

#41
post #28
post #6

Yet another place where intuitions derived from the normal distribution about the behavior of distributions screws people. An explanation I like, from michaelochurch: Let's say that you have 20 tasks. Each involves rolling a 10-sided die. If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15 minutes. If it's a 10, wait an hour. How long is this string of tasks going to take? Summing the median time…

Exponential feedback is a bitch! When I put together plans and estimates, I always take a lot of care to separate out those things which are linear and those things which exponentially impact other things within the schedule, along with the sort of inflection points. I may not know where I'm going to roll a 9 or 10, as they may crop up anywhere, but there are certainly areas where they are more possible and less poss…

In a startup I've worked on, we did estimates based on hours, but also had the "no idea" tasks. We would then make sure to alternate sprints to work on well estimated tasks (as you say, "linear" tasks) and others to work on the hard ones, without a set deadline; or split the team effort in that manner.

I think that's a better strategy than making wild guesses and ultimately falling behind schedule, but at the same time maintaining cadence, which buys you power to sometimes say "hard things are hard, I don't know when it'll be ready to ship".

Re: What We Do and Don't Know about Software Development Effort Estimation

#42
post #3

IMHO it is quite easy to make a reliable estimation of well-planned project. However it is extremely difficult to plan the project more than one step ahead of what is already done... This is why agile development is so popular. In general when under-estimating the project you can make it: 1) on time and within planned resources, 2) with all the planned functionalities and 3) without sacrificing quality. Pick any two.

> IMHO it is quite easy to make a reliable estimation of well-planned project. Evidence suggests otherwise. Sure you can estimate +/- 100-200% early on but that isn't what anyone is aiming for in a software project. Even detailed plans of repeatable (non-trivial) software projects do not result error bars that anyone really desires.

You missed the second part: "However ...". :)

My point was that it is the planning step that is extremely difficult, not the estimating one. With most real-world projects the project plan must follow changing requirements (based on external input or on things you have learned during development). It is extremely unlikely that the original plan will (or should) be followed to the end.

Re: What We Do and Don't Know about Software Development Effort Estimation

#43
Problem with estimates is that once there is an estimate the team can really stick to this estimate. Regardless of quality.

It is feasible for the team to claim that it met the estimate, and it is feasible to have all indicators green on the day the deadline is met. Simply do less design, less refactoring, less thinking, less tests, less collarborative work, less engineering...

Re: What We Do and Don't Know about Software Development Effort Estimation

#44
post #34

Earlier quoted context omitted.

"Six to eight weeks" was the default estimate my project managers gave for anything above trivial. Long enough to make the task seem difficult, not too long to scare off the client.

Do you work at Stack Exchange? http://meta.stackexchange.com/questions/19478/the-many-memes...

Ha! This was the norm at my corp over 10 years ago. Heh.

Re: What We Do and Don't Know about Software Development Effort Estimation

#45
post #9

Often a technical realistic schedule is derived and presented, but the business side deems the project cost is too high and asks the schedule to be "optimized." The optimistic scenarios of the schedule is adapted and revised. Of course reality sets in when the project goes forward and it ends up taking as much time as predicted.

That's often what I see. An estimate roadmap is presented, management expresses that it wants it sooner, the roadmap is "shuffled" and "optimized", it is approved, yet reality still sets in during development :-)

Re: What We Do and Don't Know about Software Development Effort Estimation

#46
That we don't know whether software development is subject to economy or diseconomy of scale stuck out to me.

Estimation cost (of doing the estimation, not consequences of estimation) not mentioned. Is estimation itself significantly costly relative to subject of estimation?

To the extent open source works relatively well as a development practice, how much of a role does suppression of estimation play (assuming there is suppression; harder to even pretend to hold anyone to an estimate without a contract, so why bother)?

Re: What We Do and Don't Know about Software Development Effort Estimation

#47
post #26

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. The best advice I ever got on project-time estimation (from a biology postdoc) was: make your best, most honest best effort, and then double it. When I make projections with a spreadsheet, I have a cell that copies my grand total of all costs and call that copy "unforeseen costs". I always hate bidding that hig…

The advice I got was double the number, and increase the time unit. E.g. you think the project will take 2 weeks, estimate 4 months.

I've heard that as well. I dunno, doubling seems to have worked so far...

Re: What We Do and Don't Know about Software Development Effort Estimation

#48
Does anyone know where can I read the referenced studies? I'd be interested if they looked at Evidence Based Scheduling / Monte Carlo simulation: http://www.joelonsoftware.com/items/2007/10/26.html

Edit:

One of the authors of the references has several articles available here:

https://www.simula.no/people/magnej/bibliography

but not the one referenced, although there are several newer articles.

Re: What We Do and Don't Know about Software Development Effort Estimation

#49
post #48

Does anyone know where can I read the referenced studies? I'd be interested if they looked at Evidence Based Scheduling / Monte Carlo simulation: http://www.joelonsoftware.com/items/2007/10/26.html Edit: One of the authors of the references has several articles available here: https://www.simula.no/people/magnej/bibliography but not the one referenced, although there are several newer articles.

Found a PDF for this one thanks to Google Scholar

4. T. Menzies and M. Shepperd, “Special Issue on Repeatable Results in Software Engineering Prediction,” Empirical Software Eng., vol. 17, no. 1, 2012, pp. 1–17

http://menzies.us/pdf/12stability.pdf

EDIT:

Several of the author's articles are available here (click the PDF links):

https://www.simula.no/people/magnej/bibliography?b_size:int=...

From looking at Google Scholar it looks like there are many newer articles on Software Estimation that the OP does not reference so may not have read.

Edit 2:

This paper talks about Monte Carlo Simulation:

https://www.simula.no/research/se/publications/Jorgensen.200...

Post reply on HN