Brogrammer Killed The Requirements Engineering Star
Here are a couple, seemingly contradictory facts: we, as an industry, understand much, much more about how to write software securely today than we did ten years ago. And – fact number two: there’s far more, insecure software being written today than there was ten years ago. Why?
There are lots of possible explanations, but I’ll cut to the chase: I think it’s Mark Zuckerberg’s fault. OK – I know. That’s not fair. After all, Facebook’s creator and CEO is only 28 years old and – gifted though he is – wasn’t much of a factor in shaping the software engineering profession before about five years ago. Still, I think we can find a lot in Zuckerberg and The Social Network – the movie that celebrated his meteoric ascent from Harvard University undergrad to billionaire – that helps explain why software quality is nose diving, despite heightened attention to the material and reputational risk that buggy, insecure software can cause.
If you recall, The Social Network delves into the early days of Facebook, which began as a dorm room project by Zuckerberg to create a “Hot Or Not” type site for the Harvard Undergraduate population. Eventually, Zuck tweaked the idea to make a plain social networking site – like MySpace, but more exclusive. The movie, which won three Academy Awards, is peppered with scenes that highlight Zuckerberg’s coding prowess, as well as those of other, technically gifted “coders” who joined the company early-on.
In one scene (http://youtu.be/4c0lk-LtLI0), the “Sean Parker” character visits Zuckerberg in the Bay Area home he’s rented and is using as Facebook’s headquarters. The house is filled with college-aged coders “wired in” – coding furiously away to the exclusion of all else. In another scene, a group of applicants for a summer internship at the nascent company are asked play a drinking game that requires them to do shots while hacking into a “fully patched Python Web Server” (I guess the Zuck wrote that?) “Every 10 lines of code, they have to drink a shot,” the Zuckerberg character explains. (http://youtu.be/uxKmDWDUZ5A)
So what’s the problem? None, really – The Social Network is a great movie. But, let’s face it, the kind of “coding” you’re doing when you’re “wired in” isn’t likely to be very careful or – need we say – secure. By setting that kind of activity as the hallmark of a gifted programmer, Aaron Sorkin’s movie is a paean to what’s been called “brogrammer” culture – a fusion of frat-house style party culture and…well…computer science. Brogramming’s been blamed or has been blamed for creating workplaces that are hostile to women and – generally – dumbing down the profession.
Whatever else it may have done, the focus on flashy, testosterone-fueled “competitive” coding divorces ‘writing software’ – free form, creative, inspirational – from ‘software engineering,’ its older, more thoughtful and reliable cousin.
That’s really too bad, because what we need now, more than anything, is a return to a more sober and methodical approach to software development. That’s the point of a great opinion piece by computer scientist Leslie Lamport in Wired. His piece, “Why We Should Build Software Like We Build Houses,” makes a long overdue argument in favor of slowing things down and turning software development into the methodical, engineering-heavy discipline it has been for much of the last half century.
Lamport, a winner of the IEEE John von Neumann Medal is an expert on distributed systems and a member of the National Academy of Engineering and the National Academy of Sciences. He says that building software should be conducted in the same way that we build houses – with plans and forethought.
“Architects draw detailed plans before a brick is laid or a nail is hammered,” he writes. “Programmers and software engineers don’t. Can this be why houses seldom collapse and programs often crash?”
Lamport takes the super-agile, ‘code first, plan later’ culture head-on. “Most programmers regard anything that doesn’t generate code to be a waste of time,” he says, adding: “Thinking doesn’t generate code, and writing code without thinking is a recipe for bad code.”
Writing functional and technical specifications – even for simple programs – is a vital skill, forcing programmers to think through what it is they want to do before they start doing it. They’re also invaluable for the generation (or two) of programmers who may need to modify or update your code after you’ve moved on. Trying to make even simple changes to a program without introducing new bugs requires a detailed understanding of what the program or function is supposed to do and how it was written. Without proper documentation, that job becomes much, much harder, Lamport says.
Of course, Lamport isn’t voicing some heretical new theory. Requirements engineering has been considered an integral part of the software engineering process for more than thirty years. The idea is that careful requirements planning should be the first stage in sofware development, leading to the creation of detailed software specifications documents that describe the function and structure of the software to be written. Alas, my conversations with other security experts suggests that such activities are more the exception than the rule and that – even in high risk and high stakes fields, like medical devices and critical infrastructure, requirements engineering is becoming less common.
There are arguments against Laport, for sure. The modern market for software is populated with buyers who demand flexibility and speed. The rapid shift to web based computing has made it possible to use agile programming methods and rapid versioning to speed up the evolution of new applications. The days of writing monolithic software applications and leaving updates to annual or semi-annual patches are long gone.
Software development has also moved from being a rarefied profession to a (nearly) ubiquitous skill. Maybe, then, its unrealistic to expect there to be only one kind of software creator – the “software engineer.” “Coders,” “Programmers,” or “Brogrammers” may see their role as quite different from the “software engineer.” They may not consider higher level planning and specification writing to be part of their job description.
But – in the end – is there really any excuse for sloppy, poorly planned work of any kind? It may be true that software doesn’t fail in the highly visible and kinetic way that, say, a suspension bridge does. But that doesn’t mean that the consequences of insecure or poorly crafted software aren’t real and costly for our society.