IBM's infamous "Black Team"
t3.org
t3.org
Or is my understanding of a tape drive incorrect, and they would wind and unwind at a set rate? Because the original article said that it would often stop, rewind, move forward to retrieve data.
Also, I think the point is that it's the Black Team's job to minimize bugs shipped, and they were really impossibly good at it. It was the programmers' job to write bug-free code, and this guy was inspired by the Black Team to write perfect code. It seems like both sides were doing exactly what they were supposed to do.
There's the classic story of "Walking Drives" from esr/jargonfile:
http://dictionary.die.net/walking%20drives
Or search for "washing" here for the story about huge DEC drives being ripped apart: http://www.rinkworks.com/stupid/cs_drives.shtml
Old hardware employed a lot of force, so "bad things" (TM) really could happen.
Actually, I probably wouldn't, because if it had occurred to anyone that they ought to ensure that the bridge design had no high-Q vibrational modes, the problem would have been found and averted before the first caisson was sunk.
That's the problem with "elite" teams in organizations. You don't get the actual elite. You just get the best connected, and they think they're untouchable.
In any case, that's funny, I bet Hofstadter based the example on this story of the Black Team.
I suspect that some hacker wanted a version of the Black Watch to look up to, so he invented one. I don't object to the invention of legends, but we should include some traditional legend-flagging phrases: "long ago", "never heard from again", &c.
And said book does have the mustache twirling.
It's so true that bugs are now simply part of life, and it has to do with the speed at which development must happen. I wonder what the Black team of old would think of today's web development wild west sort of approach.
Here it is: http://www.fastcompany.com/node/28121/print - They Write the Right Stuff (2007)
There's also another story (google fails me) about a legendary IBM programmer around whom IBM built an entire team of testers, documenters, etc, all to keep this one guy's way above average productivity going. That story also makes me sad.
These stories make me sad because I know how huge a difference the environment makes to everyone's job.
The key points about the black team:
1. A few individuals that happen to be a bit above average at finding defects.
2. Bring them together, create a team.
3. Support them, but mostly just get out of their way and don't distract them with management B.S.
Very little change and support results in a huge jump in their productivity!
Same thing with the single legendary programmers, simply relive him of non-programming tedious tasks, give him enough support staff to keep up with his output and again HUGE productivity boost.
What's so sad about this is that is so rarely happens. I think most people are capable of having this productivity jump, if only they'd get the same support. OK, let me back of a bit from most and be more precise and say, you should be at least a bit above average.
But why does this so rarely happen? Sadly I think for most sizable companies minor process changes are a huge obstacle.
The bright side of this? Startups. Startups are like these kinds of teams within a behemoth like IBM, except without the behemoth. Or actually a startup up ought to be like that, because that is one of the key advantages a small business should have over the big ones.
But I did witness first hand some shenanigans done by the Field Engineers on XDS tape drives in the 1970s. They did use a kind of resonant thing to test the limits of how well a particular tape drive was working. It would do a lot of rewinding, stopping, reversing and the like. These drives had long vacuum (work with me here) chambers, one on each side where a loop of tape would be suspended. Thus, a fast back-and-forth operation could be performed on a short section of the tape without moving the reel. The goal was to try to get the tape moving in such a way that it would pop out of the vacuum chamber and fault the tape drive.
Somewhat like the Black Team's efforts are alleged to do, the net result was that all the tape drives, after adjustment, were able to pass this tough diagnostic.
As a result, well-TDD'd code may still have defects that involve:
- the programmers misunderstood what needed to be built ("requirements" defect) - the programmers interfaced with an external system that behaves differently than they thought - the programmers used a third-party library or framework incorrectly - there is a systemic error in the programmers' approach to the problem (e.g., not knowing about SQL injection attacks)
As I say in my "Let's Play TDD" series (http://jamesshore.com/Blog/Lets-Play/), TDD does a great job of helping a programmer write the code she intended to write. But it can't check the programmer's fundamental assumptions, so it's still important to check those assumptions using other techniques.
I wasn't intending to diminish the role of QA (essential) or assert that TDD cures all (doesn't), just that The Black Team weren't doing TDD.
Indeed, this story is in Peopleware, and it surprises me that I can find no account of the Black Team which has any details other than those I can find in Peopleware. It makes me wonder whether the story is apocryphal.
Instapaper's Text view works better here.
http://www.instapaper.com/extras
http://www.instapaper.com/text?u=http%3A%2F%2Fwww.t3.org%2Ft...
Can instapaper be customized? Can I make it wider still?
There are two rectangle icons that allow you to increase and reduce the margin.
I didn't know Safari had a "Reader" button (I usually stick to FF/Chrome), out of curiosity do you know who implemented the idea first?
"Team members began to affect loud maniacal laughter whenever they discovered software defects. Some individuals even grew long mustaches which they would twirl with melodramatic flair as they savaged a programmer's code."