



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