For an industry that saw women drive some of its earliest development, IT has become intensely male-dominated. Where did it all go wrong?
Ever feel as though things are going backwards? Today, women make up only a quarter of the IT workforce in the US. In the UK, it’s even worse. The latest statistics from e-Skills UK, published in summer 2014, claimed that fewer than one in five workers involved in IT in the UK are women. Other countries in Europe do little better. The best performers are Greece and Ireland, but even in those countries women account for only 25 per cent of the IT workforce. Yet women represented the majority of those who would program the first computers. As a new industry, this perhaps should not be a surprise. Without the accumulation of decades of custom and practice and as a fast-growing sector, IT had the opportunity to forge ground in a post-war society that was meant to be more egalitarian. For a while, it seemed to be true.
In 1948 Klára Dán von Neumann wrote the very first program for the kind of stored-program computer that we are familiar with today. Grace Murray Hopper came up with the basis for high-level languages implemented first as COBOL by a team that included women such as Jean Sammet. During the 1960s, women made up a significant proportion of the staff of UK government IT projects. Even by then things were changing, although their consequences would not be widely noticed for almost 20 years.
In the US, by the mid-1980s, women earned almost 40 per cent of the bachelor degrees awarded in computing. The female IT workforce then rose to 38 per cent towards the end of the 1980s. As a proportion, there were more women working in computing than in any other form of engineering. Then it all started going backwards - the number of women enrolling in computer science courses towards the end of the 1980s plummeted and the glass ceilings that had been quietly slid into place over the previous 20 years became more obvious.
The policy that encouraged women to go into IT in the 1960s - as part of UK prime minister Harold Wilson’s programme to capitalise on the ‘white heat of technology’ - ended up driving many of them into lower-paid, dead-end jobs when the Civil Service changed its grading rules, according to research performed by Marie Hicks, current assistant professor at Illinois Institute of Technology.
Other small decisions seem to have built up over time to reinforce the image of computing as being a male-oriented industry, populated by an IT crowd that thinks differently from the rest of the population. This is despite the technology’s novelty offering an opportunity to build an industry that would be far more diverse.
In the very earliest days of the computer, women were central to software development. Part of it was due to the way that the first computer architects saw software as being a relatively small and unimportant aspect of their use. There were no programmers then; a ‘computer’ was human, someone who worked closely with the computation machine, and these were designed primarily for military use. The computers were mathematical specialists who would feed the machines with instructions and adjust each subsequent step based on the results in order to produce, for example, tables used to calculate the trajectories of artillery shells.
Thomas Haigh, associate professor in the school of information studies at the University of Wisconsin, Milwaukee, says: “There was a strong tradition of women in applied mathematics, who often would be expected to do the repetitive large scale computations.”
The IT crowd
Within a decade, the computer machinery would start to move into business. “The technology moves into a different environment and is taken up by a different group of people. The kinds of administrative and managerial work that the computer was replacing or enhancing had traditionally been male-dominated,” Haigh adds.
Nathan Ensmenger, author of the 2010 book ‘The Computer Boys Take Over’ and associate professor in the school of informatics and computing at Indiana University, says: “The sixties is this period where people realise that software is a much bigger problem than they had ever anticipated. It’s where the computer starts to meet real-world problems and those problems are somewhat vaguely defined. In the 1940s, when computers were used to calculate shell trajectories, that’s a complicated problem, but the analysis is rather straightforward. By the sixties, people are asking how they can computerise the accounts department.”
Developers would need to talk with accountants about their works and their needs to determine how a system would meet accounting rules and how users would interact with it.
“Software becomes this much fuzzier problem. It’s hard and expensive to solve these problems. Who is best suited to deal with these problems and then translate it into something that the computer can understand? How do we train and educate those people?” Ensmenger asks.
The industry focused on its most immediate problem: a lack of people who understood the inner working of the machines and who could program them efficiently. “There is an inevitability here: the inevitability of a kind of reductionism. They can’t take a long time to train people, so employers think they need to come up with a test that will filter out unpromising candidates quickly,” Ensmenger says.
The filtering process took the form of aptitude tests that were distributed widely - even to prisons - in the hope of unlocking hidden talents. The tests were supported enthusiastically by personnel departments; they were able to administer the tests easily.
At this point, opinions as to what makes a member of the IT crowd rapidly solidify. “To this day there continues to be the perception that it has to be someone who is naturally good at this. People continue to cite a terrible study on this,” Ensmenger says, pointing to the 1968 research by Hal Sackman, WJ Erickson and EE Grant from System Development Corporation, that claimed a good programmer is ten times more productive than a poor one. “It’s terrible research: there were just nine subjects in it. However, people seize on it because it seems to correspond with their actual experience.”
Leading computer scientists of the time such as Edsger Dijkstra argued against the emphasis on the idiosyncratic genius, claiming it encouraged a ‘tinkering’ mindset. Yet the push for more recruits and limited understanding of what skills IT really needed meant many companies used them well into the 1970s.
Ensmenger says: “These tests have the virtue of being scalable. You can send them everywhere. The fields we now know as human resources were just emerging. They said: ‘We can do that. We can find you lots of computing and maths types’. However what you get is an over-reliance on aptitude tests and personality profiles.
“A very small proportion of algorithmic work does look like puzzle-solving, but the other 80 per cent of software development doesn’t look like that at all,” Ensmenger says, but the tests tended to favour young men who like doing those types of puzzle. The tests fail to identify those who perform better on more open-ended problems and less algorithm-focused aspects of development.
Aspects of the aptitude test continue through to the present day, now with a face-to-face element, tending to discourage those who do not perform those tasks quickly. Ensmenger adds: “You find Microsoft and Google are notorious for these confrontational interviews on the speed you are asked to solve logic puzzles, but this approach takes on a very small element of software. IT is about understanding the business problems as well as the technical problems. It’s about documentation and teamwork, but that largely gets ignored in hiring practices.
“It comes down to solving these limited types of maths and logic puzzles. It’s a legacy that has not done the software industry much good. It discourages certain people from entering the field. It is a gender issue, but it also makes for bad software. If you ignore these other aspects of things, you end up in trouble,” Ensmenger says, pointing to the high cost of post-delivery maintenance.
“Software maintenance absorbs 80 per cent of software costs and has very little to do with programming in the traditional sense. If you draw a circle around the process of excluding everything else, that everything else doesn’t go away. It just turns into deferred cost. It’s one reason why so many projects fail.”
Some in the software industry believe a change in focus is required to address the quality problem and that may lead to a greater diversity in how IT teams are staffed.
“We were hired at 20 per cent less than men and only allowed to set up the test cases,” one woman programmer told Joan Greenbaum, currently a project adviser at the City University of New York, for her 1979 book In the Name of Efficiency.
John Paliotta, CTO of Vector Software, says: “In my career, the smartest guys were doing the implementation. The testing has always been less valued.”
On today’s machines, the precise implementation has become less important because it is rare for a function to be tuned for the greatest performance - a very different situation from the one programmers faced in the 1950s and 1960s, when every byte or cycle was precious. Now, the vital characteristic is how well those functions interoperate.
“If I have my two best guys defining the interfaces between functions, I can have the two least experienced doing the implementation. It’s the interfaces that matter. It’s turning the industry on its head to say the best people will design test cases instead. But the most skilled developers will think of anomalies and edge cases. If they build those cases, you will have a much better outcome,” Paliotta claims.
However, the industry has continued to build itself around a very narrow base focused on implementation. The rise of the personal computer and then the Internet startup appears to have increased that focus, not least in public perception. That was associated with the people who rose to the top of those revolutions, which seems to have had a further effect on the gender imbalance.
“I argue that the hacker myth that emerges out of computer lab in the seventies begins to shape perception as to who belongs in computing. Then it gets exacerbated by the enormous success of the personal computer and companies selling software for it. By the mid-1980s, we have people like Bill Gates and Steve Jobs being celebrated and we continue to tell those stories,” says Ensmenger. “But they are not true of the wider corporate IT environment.”
Haigh warns of paying too much attention to the raw numbers that show an apparent increase in the gender mismatch in academia particularly. His research points to a gradual lifting of the glass ceiling, with women increasingly moving into more senior roles than in prior decades. The e-Skills UK Women in IT Scorecard notes that the gender balance for IT staff in director or management roles is much closer than for other job grades: 20 per cent of women versus 23 per cent of men as of 2013.
Dealing with the problem
“The question that I have is: ‘What is it that women are doing instead of going into IT?’” Haigh asks. He points to the rise in the number of women going into law and medicine, although they can be more constrained by glass ceilings in those industries. “We also have to define what ‘IT work’ means today. There are so many people developing models and systems without using traditional languages. That could dwarf the size of traditional software development, but not show up in census data.”
Choice may, perversely, exacerbate the West’s gender gap. Some nations with reputations for poor women’s rights in general show relatively high proportions of women working in IT compared to men. With a good standing in mathematics among those who make it into higher education Armenia, for example, has shown consistently high female-male ratios for people working in IT. Research led by Professor Maria Charles, area director for sex and gender research at the University of California at San Diego, indicated a significant difference in attitudes to mathematics and related subjects between two groups of Asian countries: the Asian Tigers that developed technological economies during the 1990s and the Asian Tiger Cubs that lag behind. Women are better represented in IT in the Cubs than in their Tiger cousins.
Charles says: “Our cross-national research design was motivated by the surprising fact, documented in previous research, that women’s presence in mathematical and technical fields is weaker in affluent, reputably gender-progressive societies than in many poorer, more gender-traditional societies”.
The difference reflects a growing disdain for science and engineering among students as wealth increases and populations adopts what Charles calls “post-materialist values”. She adds: “Whatever the cause, we expect that people will more often act upon any aversion to mathematics in societies where the economic costs of forgoing lucrative STEM careers are more easily borne.”
Ensmenger sees some hope in the development of societies that adopted IT later, as they have not necessarily followed the same patterns as the West. If the 1960s were replayed and people made even subtly different decisions, “it could have gone in a number of different directions”.
Dealing with the problem now is a much tougher task.
Charles says to increase “the flow of women into mathematical and technical fields in affluent democracies will depend upon the erosion of two kinds of cultural stereotypes that pervade schools, universities, workplaces and society at large: those that depict women as innately ill-suited for scientific and technical work, and those that depict scientific and technical work as uncreative, solitary and fundamentally masculine.
“Sex segregation is so persistent in reputably gender-egalitarian cultural contexts partly because these seemingly free choices legitimise existing patterns of gender inequality and bias the expectations of the next generation,” Charles adds.
Software development overall has a similarly complex problem to solve, Ensmenger concludes: “The problem is we try to isolate individual aspects of software. We talk about gender problems, labour-shortage problems, technical problems. You cannot just solve one.” *