24

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

— Tom Cargill, Bell Labs

What does that exactly mean in practice? That programers do substantial amount of work and that they are giving 180% out of themselves or?

  • 2
    We all know that either 100% is redefined by exceeding it, or that it is 1.8 times a known amount. In this case, however, I'd say it's probably hyperbole. The second ninety percent is there to make it memorable, and add a punch-line to the end of the quote. – AJFaraday Dec 8 '16 at 13:43
  • 1
    The estimate for the development time changes in the middle of the sentence. – milleniumbug Dec 8 '16 at 14:27
  • The 180% is the amount of time and budget the project ends up costing. – Agent_L Dec 8 '16 at 15:15
  • 1
    I think it's perfectly clear what this question is asking despite the awkward final sentence. – Matthew James Briggs Dec 9 '16 at 6:30
  • 2
    This quote is supposed to be read as a joke, in that context it makes sense. It's saying the last 10% will take far longer than you imagined – Richard Tingle Dec 13 '16 at 9:36
40

Imagine it like this: When you start working on software you can write huge amounts of code in relatively short time. This new code can add huge amount of new functionality. The problem is that, often, that functionality is far from "done", there might be bugs, small changes (small in business small) and so on. So the software might feel like it is almost done (90% done), because it supports majority of the use cases. But the software still needs work. The point of this rule is that despite the software feeling like it is almost done, the amount of work to bringing that software into properly working state is as big as getting to that "almost done" state. That is because bug fixing is often time-consuming but doesn't produce lots of code.

The problem is that most developers estimate getting the software into "almost done" state, because that is relatively simple compared to actually estimating total effort the software will take.

  • 3
    A big part of the reason for the 90-90 illusion is that software engineers often visualize the success path - handing the error & exception cases are an afterthought. If the original design doesn't take into account the low probability error cases, it will likely need revision before the software can be called finished. – Rumbleweed Dec 8 '16 at 15:34
  • 1
    +1 but I feel the second paragraph needs some bold text because that's the really important part of the lesson :) – Matt Thrower Dec 8 '16 at 16:51
20

It is a reference to a common scenario, that sadly still occurs today:

  1. The team is asked to estimate (ie guess) the amount of work needed to write all the code,
  2. The project proceeds with numerous internal and external pressures to "stay on time and budget",
  3. So for a significant percentage of the project, "on target" is reported. This is often compounded by picking the easy tasks first to ensure good progress is made.
  4. Then at some stage, a critical point is reached where the reality has to be accepted: the project will not be completed on time and the release date gets pushed back (often many times).

"90%" is an arbitrary figure, but it makes the point well: estimates are guesses and will likely be wrong (often very wrong) and human nature ensures we nearly always under estimate, so things overrun.

  • 14
    What's being called "agile" does nothing to solve the problem; it simply distributes it among smaller items, where exactly the same ratio occurs on a smaller absolute scale, even if Cargill was being facetious. The bottom line is that every project has a couple of small things that take up a lot of the development time. – Blrfl Dec 8 '16 at 11:57
  • 3
    @Blrfl The answer does not imply that agile solves the problem of estimates being hard, but it does mitigate its consequences by making smaller estimates. – Eric Dec 8 '16 at 14:24
  • It's not only a resource management issue I think. It's very easy to quick&dirty prototype the 90% of a project, but the remaining 10% will take a LOT of time, because it's often here that we care about being fully compliant with the initial requirements. I'm in embedded systems and I can give a demo of a product to the sales guy months before the product release, and he'll see almost no difference between the demo and the final product, but for sure the demo is not shippable. Bugs, optimization, advanced features, power consumption, that's the other 90% – Tim Dec 8 '16 at 14:45
  • Trust me even with Agile shit hits the fan and blows up! – JonH Dec 8 '16 at 15:52
  • 2
    Removed the afterthought about agile as it's clearly distracting folk from the main point of the answer. – David Arno Dec 8 '16 at 15:54
7

I have heard a different version of this (also called "90-90 rule") that goes like this:

After I have implemented 90% of the functionality, I still have to implement the other 90%.

Both versions refer to the difficulty of correctly estimating effort for developing software products and the common pitfalls that people tend to fall into:

  • throwing statistics out there when estimations are required and essentially guessing ("I am 80% done")
  • focus on algorithmic complexity of the code to be written, at the detriment of volume of work (underestimating required effort for common tasks)
  • missing steps ("out of sight, out of mind")
  • underestimating effort for maintaining and changing existing code
  • underestimating effort required for the boilerplate/"glue" code
6

This rule complements the 80-20 rule. Now, there are many different interpretations of the 80-20 rule, but the two I like the most are:

  1. The first 80% product development takes up 20% of effort.
  2. 80% of errors are in 20% of the code.

In practice, this means the following: the development will start and move on until some certain point when the first delays will be noticed. The delays can be of various nature:

  • Poor quality control, resulting in bugs
  • Additional requirements that the customer came up with along the way (and the reasons for this can also be multiple)
  • Unclear requirements from the start, which result in dropping parts of previous development (which might also result in regression bugs)
  • Initial underestimations due to unclear scope, human error or unpredicted circumstances. These unpredicted circumstances can be sick leaves, resignations, hardware failures, or, in extreme cases, volcano eruptions (once we had to delay a project because we could not fly on-site due to a volcano eruption on Iceland).

Bottom line is that it is much easier to come near the goal than to actually reach it.

4

I find Wikipedia explanation quite enlightening:

This adds up to 180% in a wry allusion to the notoriety of software development projects significantly over-running their schedules (see software development effort estimation). It expresses both the rough allocation of time to easy and hard portions of a programming project and the cause of the lateness of many projects as failure to anticipate the hard parts. In other words, it takes both more time and more coding than expected to make a project work.

1

What does that exactly mean in practice? That programers do substential amount of work and that they are giving 180% out of themselves or?

No, programmers always do same amount of work per unit of time. The quote is about under-estimating cost and overruns. The 180% is the amount of time and money the project ends up costing.

It roughly means "It will take you twice as long as you think" and "You'll think you're doing well until it's already too late (the deadline is near)".

1

What this means in practice is that people lie to themselves.

If a programmer says "we're 90% done" it means 90% of the effort to build the features has been expended.

If a project manager says "we're 90% done, I just need someone to finish it" it means they're 90% through the budget (and probably 50% done). This is a client with no money, high expectations, and a bad attitude.

The difference is it takes more effort than coding features to finish a project: qa, bug fixes, copy edits, deployment.

Those things need to be managed in the project, and are the responsibility of the project manager. This often surprises new PM's who coast to "90% feature complete" only to realize they are only halfway to "project done".

protected by gnat Dec 9 '16 at 15:01

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.