80/20 Rule in Software Development Revisited

You know that pesky 80/20 rule in software development, right? It seems almost inavoidable, huh?

The original 80/20 rule, the Pareto principle, states that 80% of the effects come from 20% of the causes. When applied to software development, people usually tend to phrase things differently:

80% of the work will take 20% of the overall development time. The corollary is that the remaining 20% of the work will take 80% of the overall development time.

Thing is, this often-quoted “rule” is blatantly wrong, not just because it’s a misapplication of the Pareto principle. On the other hand, there’s some truth to be found there, too.

To explain what I mean, let me illustrate this with a brief example from my own work life. Back in my first job, we were trying to land a deal with this huge customer. It turned out we were naively trying to sell them technology when what they wanted was a solution. Briefly put, they were not interested in what we did so much as in seeing what it earned them.

So in an all-nighter, my then-CTO added a page to the web app we were trying to sell, that was just a mockup of the sort of reporting interface these guys wanted. To the best of my knowledge, that closed the deal, and the next day he came to me and asked me to “flesh things out”, i.e. to make actually do what it seemed to be doing1.

His estimate? It’d take a few more days to finish. Let’s say four more days for convenience’s sake. It was more like four all-nighters. That’d be exactly the sort of situation in which people would apply the 80/20 rule: things are “nearly done” after 20% of the time, now it just takes another 80% to get them fully done.

Right?

Wrong.

Let me get one thing straight: I’m the last person to think that up-front design isn’t “real” work. I understand that the all-nighter this guy pulled was real work; not only did it seal an important deal for us, but it also gave me enough info to run with it and finish it up.

But really, development work isn’t measurable in units other than time. Strictly speaking, what happened is that 20% of the overall development time got 20% of the overall work done, and 80% of the overall development time finished the remaining 80% of work. You could’ve counted lines of code, and would’ve come to roughly the same conclusion: his mockup was a hollow shell with no functional code in it worth mentioning. Virtually all the functionality came afterwards.

And if we’re nit-picking — and I love to do that in cases like this — these four extra days were the bare minimum required to make the mockup not break. Until we got the full functionality in place, it required a total rewrite, a new design from the ground up, and three or more weeks of hard work. But that’s just to finish the anecdote, it’s not really important to the discussion.

So 20% of the time equal 20% of the work. How come, then, that the 80/20 rule of software development is so popular?

It’s because software development is different from pretty much all other work I’ve experienced, in one important aspect: it’s entirely possible to build such a hollow shell that looks complete, but is far from. Try to do the same with, say, architecture, and you’d have to invent anti-gravity fields to hold the hollow shell up while you fill in the load-bearing walls.

So really, the rule should be that after 20% of the work, software can give the appearance of being 80% complete.

And with that rephrasing, the Pareto principle is applied less haphazardly to software development: 80% of the effects (appearance) come from 20% of the causes (work).

So when you next cite the 80/20 rule, why don’t you cite it correctly?

  1. This turned out to be a common pattern in the later years of my career. []

  • Bly314

    You basically have a critique on the 80/20 rule for software. While believing that some simplistic 80/20 rule is actually valid is a real problem in software, I’ve heard some people rationalize your story here in a different way. For example, my former video game boss loved to say that 80% of the work can be done in 20% of the time. Of course, the remaining 20% of the work is more difficult and therefore takes more time. This rule, according to this boss, applies to work in this way. Often you will find that perfecting a thing takes forever, and that is what my boss would say. Making a good product better takes a lot of time. It is just that the finishing tasks on any product are more likely to be those that are not templated or provided for by libraries or easily written routines.

    • http://www.unwesen.de/ unwesen

      Right. I’ve heard different ways to rationalize the rule, too.

      If you rephrase the thing your boss said a little, namely that 80% of the tasks are so simple that they can be done in 20% of the project time, then I’m even inclined to agree somewhat.

      But to me, the only sensible way to measure work is by time spent. That’s the only measure, at least, that lets you plan ahead with some amount of confidence. It’s the measure I use to bill people in my consultancy work, too.

      It’s not as if in the 80% of time spent on those supposed 20% of work you’re slacking off, you work at least as hard as the rest of the time. I assume that, that is :)

      • Bly314

        There was a paradox proposed by Zeno a long time ago regarding a race between a tortoise and a hare. I think that the 80/20 rule works a lot like Zeno’s proposal. The first 80% of the work takes x hours. Now, the remaining 20% of the work needs the 80/20 rule also. So, that means the next x hour chunk of work will finish 16% more of the work( 80% of remaining 20%). And the subsequent x hour chunk will finish 80% of the remaining 4%. Now we have about 1% of the work left. However, as you see, you will never actually get to the perfection of the product, no matter how much time you spend on it. The key point here is that as you get closer to the goal, it takes longer amounts of time to finish smaller amounts of work.

        The real key is to know when the product is “done” to satisfaction. In the video game industry, “done” is a subjective concept and therefore there are a lot of late nights before a gaming show or before a release.

        • http://www.unwesen.de/ unwesen

          “Done” is a subjective concept with any work that requires creativity, I think :) Most of the time you can think of more to do that’d provide incremental improvements.