Information Technology Reference
In-Depth Information
The central assumption of all such aptitude tests was that there was
a particular innate characteristic, or set of characteristics, that could be
positively correlated with occupational performance. These traits were
necessarily innate—otherwise they could simply be taught, rather then
only identifi ed—and tended to be cognitive, personality related, or some
combination of both. The Thurstone Primary Mental Abilities Test, for
example, claimed to evaluate specifi c skills, such as “verbal meaning”
and “reasoning,” as well as more general qualities such as “emotional
stability.” The verbal meaning section presented a series of words for
which the test taker would have to identify the closest synonym. The
reasoning section involved the completion of number series using rules
implicit in the given portion of the series. The emotional stability ques-
tions purported to measure an amalgam of desirable personality traits,
including patience and a willingness to pay close attention to detail.
The scientifi c validity of aptitude testing was at best equivocal. At an
Association for Computing Machinery conference in 1957, the com-
pany's own psychometrician, Thomas Rowan, presented a paper con-
cluding that “in every case,” the correlation between test scores and
subsequent performance reviews “was not signifi cantly different from
zero.”
41
The best he could say was that scores on the aptitude test did
correlate somewhat with grades in the programming course. Nevertheless,
SDC continued to use aptitude tests, including those tests that Rowan
had identifi ed as unsatisfactory, as the primary basis for its selection
procedures at least until the late 1960s.
Why persist in using aptitude testing when it was so obviously inade-
quate? The simple answer seems to be that SDC had no other option.
Having accepted a $20 million contract from the Air Defense Command
to develop the SAGE software, SDC necessarily had to expand rapidly.
Even had SDC managed to hire away
all
of the computer programmers
then working in the United States, it could still not have adequately
staffed its growing programming division. The entire SDC development
strategy had been constructed around the notion that complex software
systems could be readily broken down into simpler modules that even
relatively novice programmers—properly managed—could adequately
develop. The SDC software factory was a deliberate attempt to industri-
alize the programming process, to impose on it the lessons learned from
traditional industrial manufacturing. Like all industrial systems, the
software factory required not only new organizational forms and pro-
duction technologies (in this case, automated development and testing
utilities) but also new forms of workers. As with the replacement of
