Pareto and headache

Raganwald asks:

  1. 20% of the features are responsible for 80% of the headaches of software development, and;
  2. 20% of the features are responsible for 80% of the value of the software to its users.

Are those the same 20% of the features on your project? If not, why not?

I cannot decide if that is a rhetorical question or not, so here’s my answer:

At the beginning of a project, the two are unrelated. What happens to them during the project largely determines its success.

A good team quickly notices which features cause more headaches. They will ask if the expected value of these features is great enough to justify the pain. If not, they throw those features away. The longer the project lasts, the more aligned the values of the features are to the pain they cause.

There are at least two ways to fail in this. First, the team may not notice early enough that a feature is painful. When they do notice, the pain of an alternate path may have grown beyond the expected pain of finishing and maintaining the feature.

Secondly, the team may be unable or unwilling to choose an alternate path. They have a contract or a boss or a mindset that tells them to finish the software the way it was originally planned.

Unfortunately, in most projects I have participated in, there has been little overlap between the painful and the useful features. I believe the same holds true for the industry in general.

A word of warning. If you think this is an argument for agile development, think again. If you think this is an argument for waterfall development, think again, too.

2 thoughts on “Pareto and headache

  1. I fail to see how this is not an argument for agile (or at least iterative) development. Time-boxed iterations specifically limit the painful type of feature, and frequent prioritization increases the valuable type of feature.

    The only gray area is features which are cheap to develop, but expensive to maintain. Again though, some agile practices attempt to limit this impact through the use of automated tests, whereas there is nothing in waterfall to prevent it from occurring.

  2. Antti Tarvainen says:


    What really matters is how quickly you can find out a the true cost of a feature reasonably accurately. Sometimes the fastest way to do that is to start coding the feature and see how it feels. Sometimes its faster to postpone coding, and do big up-front design.

    Up-front design is like doing mini-sprints in your head and on paper, without the cost of coding and refactoring. Naturally, sometimes you fail, and will come out thinking things are cheap when they are in fact costly, or the other way around. It is hard to say at which point iteration through coding becomes riskier than iteration through design.

    A case can be made that this style of design _is_ agile, but I would rather not go there. There’s a tendency to take everything that is good and beautiful, and call it agile, but I would rather call it just good and beautiful.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s