The computing world was different in the 1960's. Computers
were massive, expensive, and required full-time staff just to keep
them running. Product cycles were scheduled in years not months.
Tasks modern programming tools do in seconds took weeks. And whenever
a new computer model was developed, the operating system and all
applications had to be developed from scratch.
Perhaps the most significant difference, however, was that despite
the tremendous complexity of building computer systems in this manner,
customers insisted that these systems work correctly. Today, software
vendors have conditioned us to believe that bugs are an inevitable
part of software, but in the 1960's a buggy operating system was
properly considered to be a defective product. Customers do not
pay for defective products.
These software defects were costing IBM a great deal of money,
and something had to be done. Management noticed that certain software
testers were 10 to 20 percent better at finding defects than their
peers. By putting these people on the same team, they reasoned,
they could form a group that would be 10 or 20 percent more effective
and then put the team to work testing the most critical system components.
It didn't turn out that way.
The individuals who made up the team were not exceptionally intelligent
or talented, but they all enjoyed testing software and were better
than average at it. When these like minded individuals were assembled,
they they spent their working hours, lunches and sometimes free
time collaborating on how to better find software defects.
Soon the members of team were twice and then dozens of times more
effective than their peers, and they began to view their jobs not
as testing software, but as breaking software. Team members took
a well-deserved pride in their abilities and began to cultivate
an image of villainous destroyers. As a group, they began coming
to work dressed in black and took to calling themselves "The
Now, IBM in the 60s was not exactly known fostering creativity
in the workplace. Corporate identity was bound up in dark-blue suits
and starched white shirts. Management, however, not only tolerated
what was happening, but loved it. Perhaps they felt some admiration
for a group so passionate and dedicated, but the bottom line was
that software quality was improving at a rapid rate.
Things soon began to get a little crazy. 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.
And the things they did to software went beyond all bounds of rational
use testing and were more akin to software torture. The crazier
things got, the more effective the team became.
To be clear, the Black Team took all of this quite seriously, and
there was nothing akin to camaraderie with the rest of the development
team. Programmers had a certain amount of respect for the Black
Team, but by and large, they feared them. A member of the Black
Team was the last person a programmer wanted to see walking towards
him, and more than one programmer was reduced to tears while having
his code evaluated by the Black Team.
As much as the Black team was feared, engineers aspired to membership.
When one member left, the team itself would select another to replace
him, and so team stayed in existence and retained much of its character
and effectiveness long after all of the original members had departed.