When I was working at UniPress in New Jersey, we had an SGI Iris. Those things are fucking heavy! It was raining outside and the office started to flood, so we had to keep taking shelves down off the wall and wedging them underneath the Iris to jack it up above the water, as it kept getting deeper and deeper.
The Indigos were another story entirely: They couldn't touch the raw graphics performance of an Iris, since the rendering was all in software, but you could actually stuff one of them in the overhead compartment on an airplane!
And then there was the SGI Indy... They made up for being small on the outside, by being HUGE and BLOATED in the inside:
"Indy: an Indigo without the 'go'".
-- Mark Hughes (?)
This legendary leaked memo has become required reading for operating system design courses:
http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassi...
Software Usability II
October 5, 1993
Tom Davis
Last May, I published my first report on software usability, which Rocky Rhodes and I presented to at Tom Jermoluk's staff meeting (with Ed, but without Tom). Subsequently, I made it available to quite a few other people.
This sequel is to satisfy all those people who have urged me to bring it up to date. I begin with a summary; details follow.
Please read at least the summary.
SUMMARY
Release 5.1 is a disappointment. Performance for common operations has dropped 40% from 4.0.5, we shipped with 500 priority 1 and 2 bugs, and a base Indy is much more sluggish than a Macintosh. Disk space requirements have increased dramatically.
The primary cause is that we attempted far too much in too little time. Management would not cut features early, so we were forced to make massive cuts in the final weeks of the release.
What shall we do now? Let's not look for scapegoats, but learn from our mistakes and do better next time.
A December release of 5.1.2 is too early to fix much -- we'll spend much more time on the release process than fixing things. Allow enough time for a solid release so we don't get: 5.1.2.1, 5.1.2.2, 5.1.2.3, ...
Let's decide ahead of time exactly what features are in 5.1.2. If we pick a reasonable set we'll avoid emergency feature cuts at the end.
Nobody knows what's wrong -- opinions are as common as senior engineers. The software environment is so convoluted that at times it seems to rival the US economy for complexity and unpredictability. I propose massive code walk-throughs and design reviews to analyze the software. We'll be forced to look closely at the code, and fresh reviewers can provide fresh insights.
For the long term, let's change the way we do things so that the contents and scheduling of releases are better planned and executed. Make sure marketing and engineering expectations are in agreement.
INTRODUCTION
We've addressed some of the problems presented in the original May report, but not enough. Most of the report's warnings and predictions have come true in 5.1. If we keep doing the exact same thing, we'll keep getting the exact same results.
I'm preparing this report in ASCII to make it widely available. It's easy to distribute via news and mail, and everyone can read it.
An ASCII version of the May 12 report can be found in:
bedlam.asd:/usr/tmp/report.text
The included quotations are not verbatim. Although the wordings are inexact, I believe they capture the spirit of the originals.
BLOAT UPDATE
"Do you want to be a bloat detective? It's easy; just pick any executable. There! You found some!"
-- Rolf van Widenfelt
[...] Read the rest at: http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassi...