
IBM's infamous "Black Team" - shawndumas
http://www.t3.org/tangledwebs/07/tw0706.html#
======
sp332
Does anyone have a link to the version where the Black Team member found a bug
in rigourously (mathematically) proven code? edit Ah, here it is:
<http://www.penzba.co.uk/GreybeardStories/TheBlackTeam.html>

~~~
sudont
It's a law of nature that you can build up a lot of energy in something by
adding just a _tiny_ bit of energy each pass. This was a bitter team that was
beaten and decided to use physics to add this tiny bit of energy each time the
tape rewound--mind you, at a steady rate _chosen_ to add in the energy
perfectly-- to embarrass somebody who had beaten them.

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.

~~~
Symmetry
On the other hand any physical system in motion is also loosing energy
constantly to friction, air resistance, and other factors. Because of that and
because the winding/unwinding description seemed implausible I strongly
suspect the story is apocryphal.

~~~
benpbenp
Sorry to nitpick, but I think this is a good thing to know. Apocryphal means
"of doubtful authenticity", not mythical or false, which is the how you seem
to be using it. The story is clearly apocryphal.

~~~
Symmetry
No need to be sorry, I'll know to use it correctly in the future. :)

------
diiq
Searching for "the black team ibm -mustaches -infamous" on google returns
(nearly) nothing. I find it astonishing that there is no record of such a team
that doesn't mention mustache twirling.

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.

~~~
blhack
If these events didn't actually transpire the way that the author of this
story suggests, does that make the story any less valid?

------
dauwk
Having worked on both the hardware and the software for most of IBM's tape
drives, from the '60s era 2400s through the '70s 3480s, which cover the time
of the Black Team, I find this story difficult to believe. On all these drives
adjusting the start/stop mechanism required the engineer to be inside the
enclosure with hands on the the very read head area whilst running many
patterns of start/stop/rewind/fast forward. If I had felt any significant
enclosure movement it would have indicated to me a major problem.

------
trickjarrett
This reminds me of the article about the developers and testers who worked on
software for the shuttle. In all the years, they only had 6 bugs ever reported
on the shuttle, all of which were fairly minor as I recall.

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)

------
bioh42_2
Reading this story makes me sad.

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.

------
wglb
I am thinking that this might just be humbug. Possibly motivational humbug,
however.

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.

------
gchucky
Does anyone know what became of the Black Team? Presumably it's a defunct
group, but when did that happen, and under what context?

------
aeontech
Lots more comments on the previous discussion:
<http://news.ycombinator.com/item?id=985965> as well as
<http://news.ycombinator.com/item?id=994358>

------
wcchandler
As a hardware tester at IBM, this makes me happy. I never see any adoration.
People think of it as a 9-5; not as a chance to "best" somebody.

------
mikerg87
I remember hearing about the Black team from a training manual given to new
hires who worked at Sperry/Univac in the late 70's - early 80's. There was a
passage where the Black Team considered it a "failure" when they couldn't
identify a defect during a testing round. And conversely they considered it a
"success" when they identified a problem. Its almost as if they were doing TDD
before anyone knew what to call it.

~~~
russellperry
Ruthless and thorough QA is a good thing, but has nothing to do with TDD. TDD
should in theory help prevent the developer from ever hearing from the Black
Team to begin with. If the Black Team found the bug, the dev's TDD fu wasn't
strong enough.

~~~
jdlshore
As much as I appreciate your praise of TDD here, there are large categories of
defects that TDD does nothing to prevent. TDD only helps programmers write the
code they intended to write. It doesn't protect against programmer
misunderstandings.

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.

~~~
russellperry
Agree with all of this, and I've made the same arguments myself. That's one
reason code coverage metrics are of limited use -- they can't measure the
quality of the tests.

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.

------
sinamdar
Nice article. This "Black Team" is sighted as an example in the book
'Peopleware: Productive Projects and Teams'.

~~~
lincolnq
FYI, "sighted" -> "cited".

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.

------
seles
It would be nice if there was info about the methods they developed for
testing, rather than just how effective it was.

------
dkersten
Pity the websites text takes up only 20% the width of my monitor... text looks
cramped and awkward to read while 80% of my monitor is blank white space...

~~~
JonnieCache
Longer line lengths are harder on the eyes. There's a reason why newspapers
and magazines use columns.

~~~
akkartik
I'm a big believer in columns. See the recent redesign of
<http://hackerstream.com> (clicking on stories or users creates new
streams/columns), and my previous project, <http://readwarp.com>

------
aangjie
All throughout reading about the Black Team, i couldn't help but recall the
Stanford Prison
experiment(<http://en.wikipedia.org/wiki/Stanford_prison_experiment>) and how
the article says a lot about how people behave in groups ... Hmm....odd,given
the goal of the article..

------
BasDirks
If anyone doubts whether they should read this article, let me quote:

"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."

