Slashdot Mirror
Open Source Pioneer Michael Tiemann On the Myth of the Average
StewBeans writes: In a recent article, Michael Tiemann, one of the world's first open source entrepreneurs and VP of Open Source Affairs at Red Hat, highlights an example from the 1950s US Air Force where the "myth of the average resulted in a generation of planes that almost no pilots could reliably fly, and which killed as many as 17 pilots in a single day." He uses this example to argue that IT leaders who think that playing it safe means being as average as possible in order to avoid risks (i.e. "Buy what others are buying. Deploy what others are deploying. Manage what others are managing.") may be making IT procurement and strategy decisions based on flawed data. Instead, Tiemann says that IT leaders should understand elements of differentiation that are most valuable, and then adopt the standards that exploit them. "Don't aim for average: it may not exist. Aim for optimal, and use the power of open source to achieve what uniquely benefits your organization."
"(i.e. "Buy what others are buying. Deploy what others are deploying. Manage what others are managing.")"
Who wrote this article?An average person?
they are called managers
They get 3 people - one of which is married, one gay, and the other refuses to date someone as tall/fat/stupid/poor as them.
People just don't understand the selectivity of multiple and requirements.
excitingthingstodo.blogspot.com
Did I miss the part of the story that explains HOW it managed to kill 17 pilots in one day?
>> Red Hat VP: IT leaders who think that playing it safe means being as average as possible in order to avoid risks (i.e. "Buy what others are buying. Deploy what others are deploying.")
Why isn't this article entitled "Red Hat Linux executive tells the sheeple to quit buying Red Hat Linux - there are plenty of identical and cheaper alternatives available?"
just because someone else said that is what you should do. There are plenty of good open source software projects out there, but there are a lot of bad ones too. Choose software because it works and solves a problem for you, not just because it is open source.
So Systemd happens with his blessing?
Thanks for doing your part in ruining Linux with the posion of systemd in Redhat distros.
Many look at a technology and say "it's good enough, it does 80% of what I need". Then they cobble together 9 other technologies the same way and you're left with 0.8^10 "enough", leaving you fighting fires from the lack of custom configuration that you need. Technical debt is multiplicative with other technical debt.
For every 1 person that reinvents the wheel, 9 others use an existing wheel for the wrong job or misconfigure the wheel because they don't understand their problem well enough. If you truly understand your current issue, you're smart enough to create a solution. Every time someone treats a tool like a black box of magic, looking at you programmers blindly using libraries without understanding how they work, it's because they don't understand the problem they're trying to solve.
P.S. Understanding what something is doing does not mean you know the exact details of the implementation.
For example, in this particular plot, the data tells us that most men and most women in this survey are 30-35 years old. But that average...
Let me stop you right there. Do you think having 2.4 children is normal?
For example, the average person has approximately 1 testicle.
File under 'M' for 'Manic ranting'
"Buy what others are buying" is good for getting experience with what others are using, which is useful if you think you might someday need a job somewhere.
Is it me or is timothy the only who posts stories now? Did the rest of the /. editors get removed with the acquisition?
it's an old story
> open source over proprietary ...
>
> Choose software because it works and solves a problem for you, not just because it is open source.
Proprietary software can get Diced, and there's a good chance that'll eventually happen to the one you choose.
At my last job, the first major project I was assigned to was replacing some proprietary software with open source for one of our critical systems. The proprietary system was originally chosen because it looked liked it worked (in vendor demos) and it seemed like it would solve most of the problems it needed to solve. Once it was actually used in production, they found that it mostly worked, and kinda solved a lot of problems, but created new problems. The vendor wasn't too enthusiastic about fixing things and certainly wouldn't add needed features because they were (once again) moving on to their "next generation platform". After a few years, our needs changed a bit, new requirements came up, and the old proprietary system really wasn't working well at all.
We downloaded the most recent version of an open source solution, called Moodle, and took a few minutes to set it up. Rather than watching the vendor's sales people demo it, we could actually try it out, and try loading our actual data into it. It actually worked with our real data, and could be integrated into our other systems. An idiosyncrasy or two was handled by adjusting the appropriate line of code and submitting the fix/improvement back to the FOSS project. After it went live in production, departments asked "can it do this? It would be great if it could do that.". For each feature, it it didn't already have the feature, I took a few hours to write a little plugin implementing the requested feature. A few years later, I'm even more confident FOSS was the right choice - it's basically impossible to have a major roadblock with the software because in the worst case we could just add a little plugin to have it do whatever we want.
In the very worst case, the project -could- completely change direction, and the organization using it could just keep using the version that already works well for them, applying any commits they want from the new version.
The best that can be said about any proprietary software you're thinking about adopting is that it looks like it will handle your needs, for the moment. Open source will continue to handle whatever needs come up, given that you form a relationship with either the sponsors of the project or any programmer of your choosing to handle the plugins and patches that you want to have as the need arises.
For that reason, open source is objectively better and more reliable on the "solves problems" and "it works" metrics, because it'll continue to work next year - it won't be dropped when the vendor is sold to Dice.
Of course, as you said, there is such a thing as bad proprietary software and bad open source software, and you want to avoid choosing bad software. Given to pieces of software that appear to be roughly equally good _at_the_moment_, the open source is better because the risk of insurmountable problems down the road and vendor lock in is essentially removed.
Proprietary software can get Diced, and there's a good chance that'll eventually happen to the one you choose.
That isn't so! We just ported all our stuff to Windows 8 and re-trained all of our employees. It's a good system and will be around for the foreseeable future .... [Just a sec. Gotta deal with all these 'Upgrade Now!' popups].
Have gnu, will travel.
Can't do anything unless it's best practice.
Best practice of course is defined as "Everyone else is doing it."
Which translates to "Nobody ever got fired for buying IBM."
Which is true right up until it's not.
Yes, we all hate SAP. Yet we all buy it. Why? It's the stock market effect in the software acquisition process. We fear that the competition knows something about the product we don't and so gains a benefit over us. Office packages are strategic weapons, capable of paralyzing whole cities at once, you see.
Determining what's optimal is hard. Determining what everybody else is using is easy.
If it's really at the core of your business, then sure you should know. But for everything else I still haven't seen a single case where a business buying non-trivial software really knew whether or not you could fulfill all your business requirements before committing. In many cases it was even recognized that you're just looking for a tool that's good enough and try to make it work for you. Like I know every component in my computer. I can barely remember the brand of my washing machine. Now obviously I need to wash clothes, but an average machine for average needs should be fine. If they're not mainstream that usually means they have some special capabilities I don't need and don't want to pay for or they have particular limitations that make them useful for particular niches. Neither is good for me.
And very often it's not just a tool for today, but also for tomorrow and shifting needs. Like say I figure the games I play on Steam today run under Linux, but tomorrow there's this super cool game I badly want to play but sorry, Windows only. Okay maybe not such a great example but at least in business you build processes around it and really the worst you can end up with is a tool that just won't do the job and require you to migrate away. You end up spending so much money just getting back to where you were, before you start getting a net return on switching. There's a reason COBOL is still around...
Live today, because you never know what tomorrow brings
The article misquotes an excerpt from a book here:
http://www.thestar.com/news/insight/2016/01/16/when-us-air-force-discovered-the-flaw-of-averages.html
This explains more of the story: the measurements were originally taken in 1926, but it wasn't until the 1950's that increased speeds for fighters made the design flaws apparent. The 17 deaths is an agile enterprise adaptation of 17 non-fatal crashes. Anyhow, it seems intuitive that body measurements would be correlated, so I'd say the big error was not checking that assumption. Kind of amazing bad science lasted that long.
Of course requirements change over time. When the current solution doesn't quite fit the new requirements, you get / write a module / plugin or patch to handle it. Unless you were short-sighted enough to make your business dependent on proprietary software that you're not allowed to adapt to your needs. If so, then yeah you have to start over with a new solution. Hopefully the second time you choose a modular open source solution so that you aren't in the same jam 12 months later.
possibly intentionally.
The reason people are so conventional is what economists call "agency costs". They aren't minimizing risk to their employers, they're minimizing risk to themselves.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Did I miss the part of the story that explains HOW it managed to kill 17 pilots in one day?
No, you didn't miss it because it wasn't there.
The definition of a "myth" is a good story that didn't really happen. This seems to cover this alleged airplane: it's a nice myth, but don't expect it to be real.
If there's a 30% chance that someone will fall within the designated "average" range
Why would you assume there's only a 30% chance of that someone would fall within the middle 30 per cent of the range?
What the author said was:
...the “average pilot,” which Daniels generously defined as someone whose measurements were within the middle 30 per cent of the range of values for each dimension.
Depends on what you mean by "middle 30%". I assume that this meant "the range of values within which 30% of the population falls." I suppose it could, alternately, be interpreted as meaning "a pilot whose measurement falls at a value of the average plus or minus 15%."-- that is, if the average height is, say, 60 inches, the "middle 30%" means height of 60 inches plus or minus 15 inches.
My uncle is 6'2 and flew reconnaissance F4 Phantoms in Viet Nam. Just what is the height constraint?
http://work.chron.com/air-forc... states:
Pilots have to meet the Air Force’s height, weight and physical conditioning requirements. They must be 64 to 77 inches tall when standing, and 34 to 40 inches tall when sitting...
77 inches is 6 foot 5 inches, so looks like your uncle made it with three inches to spare.
Software that is popular with the most users is also the software that is least likely to be orphaned, leaving you to either keep obsolete machines running or else having to migrate some obscure data format into some different form.
Also, the most popular software is more likely to have the most annoying features "corrected" because so many users complain. (not to mention it has the most people posting work-arounds on the web for the things that don't work.)
It sounds like he just made an average and called it that. That's bad math. Standard deviation shows how far your average can vary.
For those of you who don't do math.
Values of 90,91,92,93,94 brings a standard deviation of 1.58 and values of 88,90,92,94,96 brings a standard deviation of 3.16. Same average of both groups, but the standard deviation shows how far out your variances go from average.
The book "The End of Averages" by Todd Rose was misquoted
First of all the exact quote from the first paragraph of the book was this:
At its worst point, seventeen pilots crashed in a single day
There is a huge difference between crashing and dying.
Anyway, he (Teimann) got the sequence of events wrong, but the general gist of what he said follows the intent of the book.
The crashing planes in the study were the in the 1940's. We're talking about planes like the P-80 and possibly the F-86.
That was the first generation of jets and they had many many problems in design.
Here's where the average pilot comes in. Those planes (the 1940's) had been designed for the average pilot's size as measured in 1926. The cockpit was non-adjustable, so The Army/Air Force sought pilots whose size fit the planes, but only that person who matched the average 1926 pilot would fit properly. In the highly demanding jets of the late 1940's, a pilot that didn't fit could have problems when split second control reactions were needed, and those planes needed it.
The study conducted by Lieutenant Gilbert Daniels in 1950 which examined modern average pilot sizes, was completed in 1952.
The upshot of that study was that the Air Force immediately decided to take the study's recommendation:
Everyone is different, and to get the maximum performance from people you adjust the environment to the soldier, not the soldier.
The Air Force immediately mandated that the manufacturers make many elements of the cockpit be adjustable for the range of sizes from 5% to 95% of men from the seats, to pedal positions, to belts, and helmet straps, and so on. The result was that pilot performance soared and the US Air Force became the most dominant air force on the planet.
The book gives other example studies and goes on to say
Any system designed around the average person is doomed to fail
This is the gist of the book and what Michael Tiemann was getting at.
Anyway, the summary implied that the generation of planes designed in the 1950's were a generation of pilot killers.
The 1950's planes had the cockpit fit problems solved.
The crashing planes were in the late 1940's. The study was begun in 1950. Obviously, those crashes were not combat-related. Those planes were demanding and possibly evil, and a bad-fitting cockpit made it worse.
See subject HEROIN JUNKY & EAT YOUR WORDS http://slashdot.org/comments.p... and fuck you... you lose, bigmouth!
APK
P.S.=> EAT YOUR WORDS, you arrogant OLD waste of LIFE funking monkey-man JUNKIE living in a fantasy you're 'smart' & you're the STUPIDEST KIND THERE IS trying to "pull weight" on me in computing you stupid zero - Tell us:
HOW DID EATING YOUR WORDS (again) TASTE?
You did it to yourself with that BIG MOUTH, you inferior DO NOTHING nobody so full of self-importance yet having to "eat it" vs. myself now? Loser... apk
Think you can "condescend"/"patronize me" JUNKY? You can't look down on others: U = LOWEST of the low http://slashdot.org/comments.p... and YOU KNOW IT... you arrogant ERRONEOUS moron!
APK
P.S.=> You sure like to "play smart" but motherfucker, when you TOSS YOUR LIFE OUT ON AN OPIATE ADDICTION needle head? IT PROVES YOU ARE STUPID to the max... & you are! apk