Ninety-ninety rule in practice

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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