You could argue that it's specifically true for projects, but the definition of average absolutely doesn't require that.

If for example you had 100 projects were 50 of them were built by expert teams who poured love into their work, and 50 were made by 12 year olds who spent one day on their projects before giving up, the "average" quality of the 100 would be a long way from either the great or the shit products.

Likewise if a group of ten people has five CEOs earning a million a year, and five waiters earning minimum wage including tips, none of the ten are "by definition" earning half a million a year.

Of course in my data sets there is a kind of "normal distribution" such that most objects are near the mean, but that needs to be found out not assumed.

I have no idea how many tech products are near the mean as opposed to near one extreme or the other, and doubt anyone could guess without bias and without actually researching the question.

I have a fairly high confidence it’s normally distributed.

Of course me having confidence doesn’t really mean anything, but I’ll work off that assumption anyway.

I think you're probably right, was just pointing out that the definition doesn't mean that has to be the case :)

Fair enough

> Most projects are average by definition. Otherwise that wouldn’t be the average.

You're assuming outliers in both directions don't dominate the process.

As an example, let's say we have 10 projects, that have some property that can be rated on a scale from 1-10. Difficulty to accomplish is the first thing coming to mind. If we have 5 projects that are a 1 on this scale, and 5 projects that are a 10, the average is going to be 5.5 despite none of the projects being anywhere close to that.

There’s way too much variance in projects for the average to be meaningful, in my opinion. They will have some or many average parts, but they will also have some number of parts that are special.

It might be normally distributed, but across tens/hundreds/thousands of dimensions. For example, some axes might be

* resource usage requirements * latency * persistent storage options (filesystem/SQL/Redis) * concurrency needs * UI options * error handling technique * etc, etc

Like, if you want a terminal-based UI and don’t need SQL access, then you definitely shouldn’t use Ruby on Rails.

Some of those dimensions are obvious at the start of a project but some aren’t. You might not find out until later that you need something that your framework doesn’t support. And when that happens, you can end up in a situation of hacking together the feature working around the framework, especially if there’s a deadline.

Like I said, frameworks are great if you are very careful with their limitations.