Does the 80/20 rule of time management apply to developers?

Question

Jeff's recent article linked to a time management example of the First Fit Decreasing algorithm, which talked about the Pareto principle (or, the 80/20 rule) of time management, that is, that 80% of the work we produce in 20% of our time.

Now we've all heard the programmer quote:

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

But all jokes aside, it is often as if 20% of your code is to do what you want, and the other 80% is to handle exceptions... so does the 80/20 rule really apply to developers?

Does anyone have any examples of why it does / does not apply to us?

Answer 1

absolutely! 80% of my time is spent on stackoverflow.com, and 20% actually working.

oddly enough, my productivity is the same as it ever was...

...same as it ever was!

;-)

Answer 2

Why do you even ask about the 80/20 rule? You quoted the 90/90 rule correctly. You already know that the 90/90 rules applies to developers.

(Sorry to respond with facts instead of a joke.)

Answer 3

2 hours of writing unittests and demoing functionality to your clients early will save you 8 hours of debugging and rewriting.

Answer 4

I think Hofstadter's Law applies.

It always takes longer than you expect, even when you take Hofstadter's Law into account.

--Douglas Hofstadter

On a more serious note, take a look at Critical Chain Project Management. It recommends that you give two estimates for each step in your project. One is an optimistic estimate that you're about 50% sure you can meet if everything goes right. The other is a more realistic estimate that takes lost time and mistakes into account (my paraphrasing, don't blame the author). Over time and several projects you'll learn which estimate is more accurate, and by how much. It varies by developer, so you need to keep track.

Answer 5

The Pereto Principle applies a lot to Developers. Some say that 80% of the work is done by 20% of the Developers. Also, 80% of the bugs are generated by 20% of the Developers. In addition, 80% of the features are used by 20% of the users. Those are the examples that I've heard of.

Answer 6

I spend 20% of my time doing what I want and 80% refactoring it.

So, yeah, if you consider that it "works" in that first 20%. But, that last 80% makes it reusable, worth maintaining, and a pleasure (instead of a burden) to use in the future.

Answer 7

I am with Bill the Lizard. It ALWAYS takes longer than expected due to very unexpected things or probably things that weren't taken into account.

Answer 8

In my opinion Kozyarchuk gets it right:

The problem isn't so much poor time estimates as it is poor/impossible scope estimates.

Showing the result, or mockups of the results to the customer/manager as early as possible, while testing the codes validity, results in better understanding of the goals/requirements.

Remember: A project is a success if it "makes the customers happy" when it is done, not when it meets the requirements known to the analyst, when the project was originally started.

Naturally this means that "moving target" is the rule, not a bad thing, and nothing to be afraid of. It also means that I, as project lead/architect, must ensure that cost for the changes in scope can/will be communicated and covered .

How is this done?

• Demo early, demo often (To users and their managers in the same room)
• Change Requests Mentality. (So the customer knows what the changes are and what those changes cost, and so the customer can use them to re-scope his project a la carte)
• Be honest, talk to customer and developers .. and make sure they also talk to each other.

Does this always work? NO

Answer 9

Yes, the 80/20 law applies to developing, but you have to interpret it differently:

• The first 80% of the code is done in 20% of the time.
• The remaining 80% of the time is not enough to do the remaining 20% of the code.