The Making of Myths

A while ago I wrote a short and quirky book, “The Leprechauns of Software Engineering.” That project arose when I started to question claims that were widely accepted in the profession; beliefs that I myself had previously accepted as fundamental tenets of software engineering.

Three major examples should give you an idea of what I’m talking about. The following are things that, as I did, people tend to accept as true as long as they haven’t done their homework:

• the notion of “10x software engineers,” that is: the claim of “10-fold differences in productivity and quality between different programmers with the same levels of experience”
• the “exponential defect cost curve,” that is: the claim that if it costs $1 to fix a bug during requirements, it will cost ten times as much to fix it in coding, a hundred times in testing, a thousand times if the software reaches production
• various claims on the extent of “the software crisis,” and specifically quantified studies of the failure rates of projects in the software industry: for instance, the well-known figures from the “Chaos Report,” or the widely-quoted “survey of $3.7 billion dollar’s worth of U.S. Defense projects” claiming 75% failure rates.

The cover of Bossavit’s book, “The Leprechauns of Software Engineering“

After hearing these repeated over and over again, I eventually started doubting. You could say that my bullshit detector was finally triggered. (I’m only embarrassed at how long that took…) In retrospect, the problem with these claims seems obvious: they are too vague to be either “true” or “false.”

No two studies ever quite agreed on how to define, let alone measure, developer productivity. Proponents of the 10x idea disagree on whether the 10x is to apply between “top” and “average,” or between “top” and “worst” (which includes “a random person picked off the street,” in which case the claim is trivial). Studies that involve “toy exercises” may not be representative of “real world” performance. Similarly, “defect” is a social construct, not one that has a widely agreed-upon, objective definition like “mass” or “amperage” do. No two studies are likely to agree on what to measure and how to measure it. This goes double for “success” and “failure,” which are extremely subjective judgements: depending on whether you ask a line engineer or the company’s CEO, you can expect to hear different stories.

Citogenesis

Despite protestations that they are backed by “decades of research,” these claims don’t actually have much supporting data. They are widely cited, but it turns out that very few people think it worth their time to locate the original sources of the research and check what the data actually said. I spent a few months doing just that for my book.

What I found was that these claims owed most of their popularity to what the webcomic xkcd dubbed “Citogenesis”.

The process goes like this: someone acknowledged as an Authority makes a fairly informal claim, like “defects cost exponentially more to fix over time.” Later authors, looking to borrow the Authority’s authority, refer to the claim as “research.” A further generation counts these indirect citations as if they were themselves original research: the claim now looks very strong, as it appears to be backed by multiple replications. Later “studies” of the same topic may take the result so much for granted that they dispense with actually collecting the relevant data, but will still be counted as additional confirmation.

Fallacies, folklore, and myth

There is a tradition in the software engineering literature, of debunking “software myths.” What the author usually means is “something people believe about software development, which isn’t in fact true.” (I think this misses the mark; I want to reclaim the term “myth” for better use.)

Previous work of this kind (Pressman’s Software Engineering, A Practitioner’s Approach or Glass’ Facts and Fallacies in Software Engineering or Brooks’ Mythical Man-Month) tended to focus on fallacious thinking. People would not explicitly say that you could get the project done in a tenth the time if you threw ten times as many people at it, but they sure seemed to behave that way. Despite the sexist language, Brooks’ insight that “the bearing of a child takes nine months, no matter how many women are assigned” was valuable. Still, the book didn’t seem to make much of a dent in the profession’s patterns of misbehaviour.

My work so far has focused on claims that I call “folklore,” or “leprechauns.” I see them as different from “fallacies” in that they are often truly and sincerely believed – I did sincerely believe some of them, until I realized there was little to no data behind them. Surprisingly, many people who heard me speak about the book told me that they still believed (in 10X engineers, in exponentially costly defects, and so on), even though they agreed with me that the data was totally unconvincing.

I eventually concluded from this entrenchment of belief that software engineering tended to be a pseudo-scientific discipline, rather than truly empirical. For a while, I assumed that this was the root cause of the profession’s problems. This, I now suspect, is only partially true. “Fallacies” were a bust; “folklore” wasn’t enough. We need a more powerful concept, that of “myth,” to understand what is going on.

Software’s continuing woes

Mainstream media often credits the software industry with sweeping societal change, captured in phrases such as “software is eating the world,” and the sector’s darlings have a reputation (reflected in large market valuations) for creating vast amounts of value for society.

Yet, though hard data and credible studies are still hard to come by, the theme of the “software crisis” continues to dominate the literature; there is widespread agreement that bugs, poorly thought out software, frequent security breaches and huge budget overruns aren’t just a fact of life, but areas where improvement would be both possible and welcome.

Then there is tech’s other side, acknowledged reluctantly, if at all: the fact that IT professions have a large gender skew; that they’re actually actively putting off people from marginalized groups, not just failing to interest them.

How can a broader concept of “myth” help make sense both of these longstanding issues, and of the software industry’s paradoxical reputation?

Seeing the myth

Go to your favorite search engine’s images tab, or go to a stock photo site. Search for “a software developer.” Look at the images; take notes on what you see. Take notes on what you don’t see.

I’ll tell you what I see. Mostly white guys; generally young; usually sitting at a keyboard, staring at the screen. Sometimes with text superimposed, an attempt at representing the abstract notion of “source code.” (Sometimes there’s a pane of glass, and we see the white guy scribbling UML diagrams on the opposite site of the glass.)

And here’s what I don’t see. I don’t see many women, many people of color. None of the types of bodies and faces I can see around me in the morning when I take the métro to work. I don’t see any users; in fact, I don’t even see any of the white guys talking to other white guys.

Those images aren’t of real software developers, of course. They constitute, rather, (part of) the myth of “the software developer.”

Myths are discourse: “text” in the most general meaning of the term – encompassing the written and the spoken word, but also pictures, songs, movies, TV shows and Internet memes.

By looking at representations of “software developers,” we are engaging in a generalized form of literary criticism. One basic exercise consists of quoting a work, then dissecting the work into the elements that explain the work’s effects on the reader, then interpreting these elements – discussing how and why they produce those effects. The relevant field of inquiry is called “semiotics” – if you want to get formal, it’s the study of how “signifier” and “signified” combine to form “signs.”

Building myths

A trope is to a myth as a brick is to a house. What I called “folklore”, earlier, I might as well now call a trope: a recurring element in discourse that has more than one layer of meaning.

When the illustration of “software developer” in an article, or the depiction of a “software developer” in a movie, features a young white male sitting by himself in front of a keyboard, perhaps with headphones on, a very specific Myth Of The Software Developer is being constructed. It is factually true that software developers use keyboards, but that is besides the point. What matters is that we are being treated to a Hollywood Hacker picture. We expect the person to type very fast, spout a lot of incomprehensible jargon, maybe twirl a pen.

The keyboard is not just a keyboard, we don’t just happen to have snapped a shot of this fellow while he was sitting and writing code (the “primary signified” in technical jargon). The keyboard has secondary meanings: it is there to remind us of the preeminence of coding in software development (a “secondary signified”), which in turns alludes to software development as a highly abstract intellectual activity, much like mathematics – demanding high powers of concentration, for which lack of human empathy and relational skills are a relatively small sacrifice.

When I say “constructed,” I don’t mean that the myth is being created from scratch right here in this stock photo. Quite the opposite. A picture like this is one more brick in the wall, a wall that is already quite strong. The keyboard is there because, in its absence, you wouldn’t even recognize the person as a programmer.

We could have constructed a different myth, one in which the canonical image of a programmer depicted the activity “talking to a person who’s going to use the software, to figure out what their needs are and how best to support them.”

Neither myth has a more legitimate – or even more necessary – relation to the way software development actually gets done, to the lived, everyday experience of people in that field. The power of myth (as Roland Barthes and others use the term), which happens to be how I want to use it for my purpose here) is that it makes you forget that it is historically contingent, that there was a time when it didn’t exist and had to be created from scratch. Myth is discourse which gets itself taken for granted. Just as we take for granted that a picture of a “software developer” must include a keyboard.

Creative Commons photo by junctions, cropped and filtered.

Use of myth and trope

The function of myth is often to reinforce a status quo; not just any aspect of the status quo, but specifically a particular balance of power. The last thing we need to understand is the interlocking, mutually reinforcing nature of the tropes that build up bigger myths.

The trope of “exponentially rising cost of defects” contributes to a myth of “software development as house building.” It emphasizes getting things right at the beginning, focusing on “requirements.”

The trope of “software as a highly abstract, intellectually demanding, nearly mathematical activity” contributes to a myth of software development as a profession “naturally” dominated by males: math is the subject of its own interlocking system of tropes, myths and stereotypes that paint it as a manly pursuit. (This has empirically demonstrable effects on women’s employment prospects. Ethnicity as well as gender can be involved in such stereotypes.)

This myth erases the inconvenient historical fact that programming was a female-dominated profession in its early years, and that many important technical innovations in the field originated with women. And it also glamorizes the field, ignoring the truth that large chunks of “IT programming” are rote and repetitive work, copying and pasting templates and adjusting variable names.

As long as these myths remain dominant, they will exert a strong influence – no matter how much we think we resist that influence – on every aspect of the industry: whom we hire, how much we “get out of the building” before writing software, how we estimate schedule and budget, who gets investor money and who doesn’t, and so on.

Myths make themselves true. That is their greatest power.

There is even a trope of “programming, motherfucker” – which aims to delegitimize people who think talking (and writing, and thinking) about software development is at least as important as actually cutting code. If you’ve followed me this far, you’ll easily see this for what it is – a force field erected to protect myth from critique.

Screenshot of the “Our Values” section on a site dedicated to selling Programming Motherfucker tshirts

If you don’t like the status quo, your best course of action is to bust the myths wide open.

Escaping myth

So what, so what? Thus goes the litany of people who have dutifully internalized the myth that articles should end on a Call to Action. “You say that the world could be different, but we already know that. What do we propose we do next?”

Do not expect me to give you “concrete advice.” To tell you what to do next. If you are expecting that, you have simply missed the point, and I must ask you to go back to the start and read the whole thing again. This is hard. Our thinking relies on myth as fish need water.

To paraphrase Jack Sparrow (or Virginia Satir, if you prefer): “the problem is not the problem; the problem is the myth that conditions our attitudes about the problem.”

The best I can do, therefore, is this: my advice is to open your eyes to the pervasive influence of culture on all the things you deplore; to acquire and use whatever tools, from semiotics or literary criticism or whatever, seem to be handy in understanding the water of myth around you.

And when you get there: write about it (or sing, or make movies). This, really, is the key thing. Not only do we need to talk more, not less, about how we develop software, we also need to talk about the things we say: we need critique.