All we really need to know about software engineering is in the film Office Space

One of the difficulties with teaching software engineering to a class of undergraduates with very little industrial programming experience is trying to convey why some of the material covered is relevant and important. For example, the importance that designing for change plays in software engineering is difficult to explain to a group of students who have never experienced the joy and frustration of maintaining a program written by someone else. After emphatically waving my arms in front of the chalk board for twelve weeks, yet feeling unable to teach my students everything they would need to know about software engineering, I would screen the film Office Space on the last day of class.

The 1999 Mike Judge film Office Space chronicles the efforts of software engineer Peter Gibbons to find peace with the role of work in his life. One of the few artifacts of popular culture (Douglas Coupland’s Microserfs being another notable) to feature a software engineer as the protagonist, Office Space – despite its enduring mass appeal and broad comedic base – embodies many subtle gems of wisdom regarding the craft of software engineering.

The following rules are all found to varying degree in the plot and characters of the film.

• design for change
• software engineering is a social activity
• an untested program does not work
• not everyone gets to write video games
• Brooks’ Law
• you will be expected to work long hours

Design for Change
We are all taught as undergraduates that maintenance is the dominant phase of the software development life-cycle. Our responsibility as software engineers is thus to design systems that are easy to modify without introducing new bugs; i.e., to design for change.

Office Space is set in 1999 at fictitious Dallas computer firm Initech where Peter, like most software engineers, is employed maintaining an existing software system. In particular, Peter is busy fixing the Y2K bug in bank software. More than eight years on, many of us in the industry have mostly forgotten about the incredible person-effort expended on fixing all that code, which obviously was not properly designed for change. The film thus serves as an object lesson in how not to design systems. It is also a historical reminder of what the Y2K bug was all about, even if Peter’s attempt to explain it to his love-interest Joanna is aborted when he intuits her waning interest. Even without reminders such as these, the Y2K crisis is likely to remain a footnote in the history of computer science for one of two very different reasons:

1. it was a such a monumentally anti-climactic non-event, suggesting the scope of the problem was severely overestimated by industry observers (and practitioners); or
2. it was our finest hour – a triumph of modern software engineering that averted a global catastrophe.

Figure 1. Samir, Peter, Michael, and Tom in cubicle hell at Initech. Whoever decided that cubicles were an ideal way to layout offices should be forced to live out an eternity stuck in a cubicle in the middle of an expansive floor pinned beneath the incessant glare of fluorescent lighting. The demoralizing effects of these wall dividers, which offer little in the way of privacy and noise reduction, are legendary. Given that software engineering requires teamwork, and cubicles are an impediment to effective communication, they should be rejected outright.

Software Engineering is a Social Activity
Software engineers write modules, classes, and libraries that are used by other software engineers in the construction of larger systems. Teamwork is thus an essential component of the process. Moreover, these systems are constructed to meet the requirements of end-users who belong to a cultural group that is usually decidedly outside that of software engineering. Interaction with this group (the customer) is an important part of the development process.
Two significant problems with this reality are reflected in the film:

1. software engineers as a whole – a point vociferously made by Business Analyst Tom Smykowski while explaining what it is he does at Initech – are not good with people; and,
2. these people with the poor social skills (like Milton) are our teammates.

It is difficult not to sympathize with Smykowski, the first to be downsized during the ongoing business process re-engineering of Initech. Like Dan’s father in Microserfs, middle-aged Smykowski has woken up to an industry that sees him as irrelevant. When asked during his interview with the efficiency consultants (the Bobs) “what would you say you do here,” Smykowski defensively explains that he takes the specs from the customers to the software people, “because engineers are not good at dealing with customers.” This stereotype of the socially challenged software engineer seems the raison d’etre of the modern day Business Analyst, whose sole job requirement it often seems is simply – as Smykowski bellows ironically – to “have people skills!” Smykowski’s plight should serve as a reminder of the need to maintain relevancy: people skills alone are not enough.

Unlike Smykowski, Milton appears so completely socially retarded as to be unbelievable. To those of us in the industry, however, people like Milton are not an aberration. Indeed, some of the best programmers I’ve ever known share many of Milton’s personality traits, which are likely related to Asperger’s syndrome and a healthy dose of obsessive-compulsive disorder (OCD). These psychological afflictions are considered by some to be an advantage when it comes to the kind of thinking required to excel at software engineering.

Figure 2. Tom Smykowski, Business Analyst. Learn to love your Business Analyst, for they have the unenviable task of pinning down and documenting the customer specifications (i.e., specs). You can always blame the Business Analyst when the system you built works according to spec, but does something stupid.

While Peter’s patience is merely strained by Milton, others who do not share his neural processing style openly mock Milton and his OCD. In particular, Initech vice-president Bill Lumbergh delights in asking Milton to move his desk simply because of the unease it causes him. Likewise, in a scene reminiscent of the alpha-male who steals the geek’s ball and claims it was his in the first place, Lumbergh’s commandeering of Milton’s red Swingline stapler is a gesture that seems predicated only by his distaste for Milton as a person. While not endemic, this kind of manipulation and bullying of the more socially challenged amongst our peers is an unfortunate practice witnessed far too frequently.

Untested Programs Do Not Work
Peter’s colleague Michael Bolton – the classic passive-aggressive nerd – feels both exploited and disrespected by his employer despite his contributions to the firm’s intellectual property. Michael’s revenge is enacted when he unleashes a virus on the credit union mainframe designed to slowly steal fractions of pennies during interest calculations. However, the program is put into production without the opportunity for testing.

As Stroustrup succinctly puts it, “a program that has not been tested does not work.” To Michael’s dismay, his virus has a bug that results in a conspicuous amount of money to go missing, resulting in the likelihood of its detection. He afterward explains to his co-conspirators Peter and Samir that he must have had the decimal point in the wrong place, and that he always makes some stupid little mistake like that. In truth, all software engineers make stupid little mistakes like that, all the time. In fact, it’s often a complete shock to me that software works as well as it does given how:

• massively complex systems have become;
• escalated the corresponding attention to detail required to maintain these systems has become; and,
• how easy it is to introduce run-time defects through simple typos and editing errors that escape compile-time detection.

This is why we test, and especially why we regression test after making even the most benign changes.

Not Everyone Gets to Write Video Games
Part of the apparent lack of job satisfaction indicated by the employees of Initech likely stems from the boring application area: banking software. We all want to work on the cool stuff, like games, artificial intelligence, virtual reality, porn websites… but let’s face it: the majority of software engineering jobs are in mundane application areas (like finance and corporate IT) that involve straightforward information storage and retrieval.

It begs the question, is Peter simply bored? Is Peter’s career crisis merely caused by underutilization and a coincident lack of motivation? The Bobs certainly feel that Peter’s problem is that he hasn’t been challenged enough, believing him when he explains “it’s not that I’m lazy, it’s that I just don’t care.” Software engineers should strive to find work environments and application areas that they find at least mildly interesting. If they don’t, they risk the predicament Peter explains to the Bobs: if your only motivation is the fear of losing your job, you will only work just hard enough to not get fired. As discussed in a previous post, software engineers instead should learn to assess their own work interest and its effect on their productivity.

Brooks’ Law
In his classic monograph on software engineering, Fred Brooks describes the phenomenon whereby adding manpower to a late software project only serves to make it later. This counterintuitive result, which has become known as Brooks’ Law, is due to many factors, including the increased overhead of communication, training, coordination, meetings, etc.

A possible corollary to Brooks’ Law is that within a software firm, individual programmer productivity is inversely correlated to company size. The larger the company, the less empowered programmers feel, or need to be; ineffectiveness can be hidden within the bureaucracy. Conversely, small companies engender ownership: employees see the direct consequences of their actions. I refer to this (purely anecdotal) observation as the Brooks Effect. Initech is a case study in the Brooks Effect. While interviewing for his own job, Peter admits to the Bobs that “in a given week I probably only do about 15 minutes of real, actual work.” The rest of the time is spent on such mundane activities as meetings, documentation, going for coffee with teammates, zoning out, filling out time-sheets (the infamous TPS Reports that serve as a running gag throughout the film), asking yourself “is this good for the company?”, playing Tetris, and eating birthday cake with coworkers.

The parody of the ubiquitous birthday celebration is recreated with particular precision in Office Space. From the uninspired singing to the disingenuous show of appreciation, no detail is left unskewered. In reality, once a company reaches the size of 50 employees, there is a statistical likelihood of one birthday cake event per week. For some inexplicable reason, this celebration is usually scheduled right before an afternoon code review. The comatose state that invariably follows can only partly be blamed on the resulting insulin shock.

Case in point, in my one year of work for Bell-Northern Research, as one of over 4,000 employees I managed to check-in to the code repository an underwhelming 16 updates to the DMS-100 digital telephone switch software. During that time span, however, I did participate in over 30 birthday celebrations and three farewell luncheons (not including my own).

You Will Be Expected to Work Long Hours
Peter’s boss Bill Lumbergh is a slightly exaggerated caricature of the prototypical alpha-male, and the film’s most memorable character. Either a programmer who rode his social skills through the management track to the top of his game, or an exemplar of the Dilbert Principle, the always coffee-sipping Lumbergh seems primarily concerned that his employees accurately complete their TPS Reports.

Lumbergh, who Peter believes represents “all that is soulless and wrong” doesn’t hesitate to ask Peter to “go ahead and come in [Saturday].” The key phrase is “go ahead”… as if to suggest that Lumbergh is doing Peter a favor by letting him work over the weekend. Software engineering – like many other professional positions such as law and medicine – is an occupation that can demand Herculean effort and extended work hours, particularly as deadlines approach. The overtime is rarely ever paid, despite efforts by jurisdictions such as California to legislate against this practise. But the legality doesn’t seem to matter, anyway, as many software engineers crave the intellectual calisthenics that programming offers, and will work overtime (or after-hours on open source projects) irrespective of compensation. In this regard, Peter is an anomaly.

When Peter fails to show up to work on Saturday, Lumbergh launches a never-ending stream of telephone calls to his home in an effort to locate and chastise his AWOL employee. This is my favorite scene in the film, not only for the comedic element of Lumbergh’s distinctive greeting that begins each of his 17 recorded messages, but because it echoes my own personal experience with two different employers. While employees everywhere have likely dealt with the inequity of the boss who parks the Porsche in the only reserved spot, the frantic cell-phone calls, pages, voice messages, instant messages, and urgent email seems particularly endemic to the life of the software engineer on the mission critical path.

Figure 3. Lumbergh asks Peter to work over the weekend. There is obviously a dress code at Initech (stated or implied) that forces all the men to wear a tie, even though they spend their day at a desk writing code. What on earth does wearing a tie have to do with programming? Why not specify that all software engineers have to wear a funny hat or wig? The tie is as necessary as a hat or wig, especially given (as Smykowski claimed) the software engineers are not allowed to meet with the customers. They made us wear a tie when I worked at IBM’s software development lab in Toronto (and made us start work at 8:42 AM because of the unionized manufacturing plant next door), except for one dude who was such a compiler genius that he got away with wearing leather from head to toe. As an aside, you know your career is progressing nicely if you get to exert more control over your wardrobe with each new position or employer. At Backstage we adopted a “pants optional” dress code because ass sweat is greatly reduced by the absence of pants. But be warned: people will make assumptions about your socio-economic status based solely on how you are dressed. The doorman Theo at my apartment building in Cape Town thought I was just a couch potato who passed his time surfing. He had judged me based on the way that I dressed, and had no idea I had a doctorate and was a president of a company. While the official uniform of software engineers is the unbuttoned dress shirt and khakis, I prefer sweat pants: comfortable, but apparently guaranteed chick repellant. “It’s a good thing you are married, because you’ll never get laid dressing like that” suggested my queer eye, Canterbury Dave from Smuggler’s Cove Pub, where I spent too much of my time as my marriage disintegrated riding the spiraling crashing waves of impotent despair from my usual seat at the bar. Of course, married or not, I wasn’t getting laid, anyway. At least the bartender used to put on the alternative 80s station on the satellite whenever I was there. But I digress.

Is It All That Bad?
Towards the end of the film, Joanna counsels Peter that it is okay to be uninspired by his work, because “most people don’t like their jobs.” This is one moment where the film rings hollow, for in my experience, software engineers love their work. We may not like our boss, and the meetings, and the politics, but at the end of the day, there is nothing else we would rather be doing.

As I ease into my 40s, Peter’s rhetorical question posed to Michael and Samir is particularly poignant: “what if we’re still doing this when we’re 50?” Personally, I sincerely hope I’m still doing this when I’m 50. As Lumbergh would say… yeah, that would be great.

END NOTES

I am amazed at how accurate the depiction of the software development process and software engineers is in Douglas Coupland’s Microserfs (Harper Collins: 1995) and his sort-of sequel JPod (Harper Collins: 2006).

Any textbook on software engineering will claim that maintenance is the dominant (longest) stage of the software life cycle. The seminal paper on how to design programs so they are easier to change is Parnas, David L. (1972): “On the criteria to be used in decomposing systems into modules,” Communications of the ACM, 15 (12), pp. 1053-58. In my experience, the adoption of early daylight savings in March of 2007 caused more software outages than the Y2K rollover.

Silberman, Steve (2001): “The geek syndrome,” Wired, 9 (12) discusses the tendency of computer scientists and engineers to exhibit autistic traits (in particular, Asperger's syndrome), and the strange cluster of autistic children born from couplings of techies in the Silicon Valley.

One of the best books on programming ever written is Stroustrup, Bjarne (1991): The C++ Programming Language (Second Edition), Addison-Wesley, from which I quoted page 380.

Brooks’ Law is from Fred Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975.

The Dilbert Principle suggests that in many companies it is the worst employees who are promoted to management, because the company cannot afford to move the productive employees out of their current positions. Scott Adams wrote The Dilbert Principle: A Cubicle's-Eye View of Bosses, Meetings, Management Fads, and Other Workplace Afflictions (Harper Business, 1996).

The requirement to pay overtime to all software engineers was later overturned by California law S.B. 88 which exempts jobs that require skill and proficiency in the theoretical and practical application of highly specialized information to computer systems analysis, programming and software engineering.

An earlier version of this essay appeared in Software Engineering Notes, volume 30, number 4, 2005.