Tuesday, February 17, 2009

Raganwald, Pareto, and Infrastructure Operations

Raganwald wrote:

My conjecture:

  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.
My question:
Are those the same 20% of the features on your project? If not, why not?

What about infrastructure:

  • 20% of the app causes 80% of the operation headaches.
  • 20% bears 80% of the user load.

How much do these overlap?

What are the outliers and how do you deal with them?

If you support more than one application, do these suppositions still apply? If so, how do you deal with them across application developer groups?


Anonymous said...

I think definitely a subset of an app's features are "the good stuff", but disruption does seem to happen because of those one or two simple-but-never-thought-of-before features. URL shortening, status updates, text-based ads... not terribly complicated features.

Disruption aside, I think really it all depends on what you mean by value. The thought-between-the-lines in your post is that if it's a hard piece that's not valuable, bag it. But valuable in what sense? Valuable to the product's core functionality? Valuable as in the tipping point for potential customers? Valuable for giving you feature parity with the entrenched leader? Measures of value definitely don't perfectly overlap. I agree that you need to put a lot of thought into what features you're coding up, not just do what's always been done, but you also need to keep in mind that "code value" != "marketing value".

As for infrastructure, I don't know. Seems like you'd want your headaches to be because of heavy load, not poor design. I'd be more curious to mix you and Raganwald and ask, how much of the 20% heavy-load is being caused by the 80% less-valuable features?

Anonymous said...

I think this is a logical conclusion - perhaps a little too general - but it's certainly been reflective of my subjective experience in software development projects.

I am not sure if I have ever drawn any particular conclusions about the overlap but actually I would wonder if other conclusions and some questions can also be made:

Firstly, the question is moot without a definition of headache versus value.

Secondly, if the 20% of features are recognised as the most valuable then are they more clearly articulated, have requirements more clearly identified, and are better tested and have better test coverage? And if so, are they the features that cause the most headache or the least?

In the infrastructure world your premise would perhaps be a little more clear-cut - assuming your dual premises are accurate. From a subjective view I am not convinced of the first premise, I think the percentage greatly varies based on a number of factors:

1. Nature of the application
2. Nature of the infrastructure
3. Middleware
4. Operations, Engineering and ADM skills
5. Operations and engineering toolsets, processes and workflow.
6. Environmental factors

The second premise is probably easier to parse though I also question its accuracy in most environments - my experience is that load spreads fairly evenly over infrastructure - the issues tend to emerge because some infrastructure is better specified, designed, tuned and configured to deal with load.

If, however, we take as valid that 80% of load is applied to 20% of the infrastructure then in my experience that 20% are usually the components that will fail. So the overlap there would be significant.

doug munsinger said...

In my experience there is overlap of maybe 25 to 35% of that problematic 20% apps giving issues and 20% having the heaviest load.

Many of the heaviest loads direct to sites that are designed to handle it efficiently and effectively, and are never part of the app problem children. Other sites may be "slashdotted" with extra traffic and become for a time the problematic app 20% as well as heavily loaded 20%.

Exactly accurate or not, looking at issues and problems in both infrastructure and software development through a lens of what has value, which is the 20% we need, and where in that do we put the effort and the time, and evaluate again against items NOT being in the 20%, but using up resources as part of the 20% problem children and needing a bit of culling, that has value in itself.