Software Estimation: Demystifying the Black Art (Developer Best Practices)

Author: Steve McConnell
All Stack Overflow 18
This Month Stack Overflow 4


by eclarkso   2021-07-03
I am really surprised no one has mentioned that a whole book devoted to this topic has existed for 15 years:

It's by Steve McConnell (also author of Code Complete) and largely covers what this author does (but more, and in more detail). I have found it consistently one of the more useful books in my library - particularly for its emphasis on error bounds and on how bad people are at estimating confidence intervals...

by ChrisMarshallNY   2021-07-03
I remember going to a conference in the 1980s (MacHack), and attending a "Software Project Estimation" workshop.

The guy basically listed excuses for padding the estimate.

Steve McConnell wrote a book about it, using a much more rigorous scientific methodology[0]. He has also written some other stuff about it[1].

This one is really the big one:

"9. Both estimation and control are needed to achieve predictability. "

In my experience, we can accurately estimate software projects that have iron-fisted control. No deviation from the plan. If we use quality-first techniques, like TDD, we can do a fairly good job of hitting targets.

Also in my experience, this results in software that no one wants to use. It doesn't crash, ticks off the punchlist, and basically sucks.

I avoid estimates like the plague (a rare luxury, but I can do it). I like to "wander down the garden path, and see what sights there are," so to speak. I call it "paving the bare spots."[2]

It results in software that comes very close to the user/stakeholder "sweet spot," with great quality. It also tends to come together fairly quickly, and allows for excellent early project visibility.

But that won't work, beyond a fairly humble scope.




by PaulHoule   2020-07-31


Also think: if the business does project A, how much money does that make for us or save for us? From a developer standpoint I have gotten the business people to tell me a value that is a fraction of the cost of the product. You fold that one and free up resources for project B which is the other way around.

by anonymous   2019-07-21

There is no general technique. You will have to rely on your (and your developers') experience. You will have to take into account all the environment and development process variables as well. And even if cope with this, there is a big chance you will miss something out.

I do not see any point in estimating the programming times only. The development process is so interconnected, that estimation of one side of it along won't produce any valuable result. The whole thing should be estimated, including programming, testing, deploying, developing architecture, writing doc (tech docs and user manual), creating and managing tickets in an issue tracker, meetings, vacations, sick leaves (sometime it is batter to wait for the guy, then assigning task to another one), planning sessions, coffee breaks.

Here is an example: it takes only 3 minutes for the egg to become roasted once you drop it on the frying pen. But if you say that it takes 3 minutes to make a fried egg, you are wrong. You missed out:

  • taking the frying pen (do you have one ready? Do you have to go and by one? Do you have to wait in the queue for this frying pen?)
  • making the fire (do you have an oven? will you have to get logs to build a fireplace?)
  • getting the oil (have any? have to buy some?)
  • getting an egg
  • frying it
  • serving it to the plate (have any ready? clean? wash it? buy it? wait for the dishwasher to finish?)
  • cleaning up after cooking (you won't the dirty frying pen, will you?)

Here is a good starting book on project estimation:

It has a good description on several estimation techniques. It get get you up in couple of hours of reading.

by JohnFx   2019-07-21

I'll let you in on a secret. Even if you were an expert with that technology, your estimate is likely to be highly inaccurate. It is the nature of the beast when doing something that is an inherently R&D task. Unfortunately management often tries to apply a manufacturing model and demand accurate estimates. To illustrate my point, consider the difficulty in accurately estimating the following two efforts:

A) Manufacture another 11K umbrellas that are the exact same as the 2K you churned out last month. B) Design a new kind of umbrella and build the first one.

Software development is B, but they are asking for an estimate assuming A.

The best you can do is break the task down into the smallest pieces possible (no more than 1/2 day each) and then triple the final number you come up with.(Spolsky Method)

Alternately, Steve McConnell has a whole book (arguably several) on this aspect of software engineering.

by anonymous   2019-07-21

Here's a link to a great book by Steve Mcconnell (aka Mr Code Complete): - Software Estimation Demystified

The basic steps are:

  • break down the pieces to understandable/workable chunks (look into workbreakdown structures)
  • if there's an item that you need more info on, note it and make sure you inform your manager ASAP
  • the piece's that you have should include items that are like others you've done before - which should make it easy to provide an est. on those, items you have some 'rough' idea about how long it SHOULD take (add a % over your gut reaction time based on your comfort level - say somewhere between 10% and 30%) and those items you just have to take a wild guess at (add a % range to those, which could be anywhere from 30% to 500%)
  • put you list of deliverables together in a spreadsheet, name each item, comfort level of completing (high to low), your time est. - which could be a range (min. 1 day to max 5 days) and any notes that could include questions and assumptions.
  • present it to your manager and discuss

A doc to talk to that includes the items needed to be completed, questions, assumptions and a range of possible delivery dates speaks a lot for your level of programming maturity - compared to someone who throws out a # of days/weeks (or just a snide remark) and never comes close. If your manager doesn't appreciate that - find a new manager.

by fenier   2019-05-12
It's not exactly fair.. and also not likely without extensive time spent doing the estimation, like sure - you can be more precise, but the more precise you need to be, the longer it takes you to frame the estimate.

Two books help with methods of doing this.

Rapid Development: Taming Wild Software Schedules:

Software Estimation: Demystifying the Black Art

This likely does mean you'll need to be allowed to deploy automated test cases, develop documentation and the entire nine yards, because it's going to be far harder to hit any reasonable deadline if you don't have a known development pipeline.

You'll need to reduce your uncertainty as much as you can to even have a chance - and even then, things will still blindside you and double (or more) the actual vs. the original estimate.

by swatcoder   2018-11-22
Estimation is often challenging and sometimes impossible, but there are in fact many opportunities to deliver reliable estimates.

If you'd genuinely like to learn more about estimating software projects and when you can do so more or less reliably, Steve McConnell's Software Estimation: Demystifying the Black Art provides a great survey of techniques.

by anonymous   2017-08-20

Two thoughts: drive quality and improve estimates.

I work in a small software shop that produces a product. The most significant difference between us and other shops of a similar size I've worked in a is full time QA (now more than one). The value this person should bring on day one is not testing until the tests are written out. We use TestLink. There are several reasons for this approach:

  1. Repeating tests to find regression bugs. You change something, what did it break?
  2. Thinking through how to test functionality ahead of time - this is a cheek-by-jowl activity between developer and QA, and if it doesn't hurt, you're probably doing it wrong.
  3. Having someone else test and validate your code is a Good Idea.

Put some structure around you estimation activity. Reuse a format, be it Excel, MS Project or something else (at least do it digitally). Do so, and you'll start to see patterns repeating around what you do building software. Generally speaking include time in your estimates for thinking about it (a.k.a. design), building, testing (QA), fixing and deployment. Also, read McConnell's book Software Estimation, use anything you think is worthwhile from it, it's a great book.

Poor quality means longer development cycles. Most effective step is QA, short of that unit tests. If it were a web app I'd also suggest something like Selenium, but you're dealing with hardware so not sure what can be done. Improving estimates means the ability to attempt forecasting when things will suck, which may not sound like much, but knowing ahead of time can be cathartic.

by anonymous   2017-08-20

Use neither min nor max but something in between.

Erring on the side of overestimation is better. It has much nicer cost behavior in the long term.

  • To overcome the stress due to underestimation, people may take shortcuts that are not beneficial in the long term. For example, taking extra technical debt thast has to be paid back eventually, and it comes back with an interest. The costs grow exponentially.

  • The extra cost from inefficiency due to student's syndrome behaves linearly.

Estimates and targets are different. You (or your managers and customers) set the targets you need to achieve. Estimates tell you how likely you are to meet those targets. Deadline is one sort of target. The deadline you choose depends on what kind of confidence level (risk of not meeting the deadline) you are willing to accept. P50 (0.5 probability of meeting the deadline) is commonplace. Sometimes you may want to schedule with P80 or some other confidence level. Note that the probability curve is a long-tailed one and the more confidence you want, the longer you will need to allocate time for the project.

Overall, I wouldn't spend too much time tracking individual tasks. With P50 targets half of them will be late in any case. What matters most is how the aggregate behaves. When composing individual tasks estimates into an aggregate, neither min or max is sensible. It's extremely unlikely that either all tasks complete with minimum time (most likely something like P10 time) or maximum time (e.g. P90 time): for n P10/P90 tasks the probability is 0.1^n.

PERT has some techniques for coming up with reasonable task duration probability distributions and aggregating them to larger wholes. I won't go into the math here. Here's some pointer for further reading:

by cvs268   2017-08-19
@otoolep Have you read Steve McConnell's "Software Estimation: Demystifying the Black Art"

(if yes, then why isn't it on your list!?)

by gte910h   2017-08-19
Check out (non-aff link)

It's a good summary on a several techniques, how to apply them, and how to pick how in depth of a one to do, as well as how to talk with people who try to negotiate with them.