Ikai Lan says

I say things!

Why “The Real Reason Silicon Valley Coders Write Bad Software” is wrong

with 12 comments

There was an article in The Atlantic this morning titled, “The Real Reason Silicon Valley Coders Write Bad Software” with the tagline, “If someone had taught all those engineers how to string together a proper sentence, Windows Vista would be a lot less buggy.” The author, Bernard Meisler, seems to think that the cause of “bad software” is, and I quote:

“But the downfall of many programmers, not just self-taught ones, is their lack of ability to sustain complex thought and their inability to communicate such thoughts. That leads to suboptimal code, foisting upon the world mediocre (at best) software like Windows Vista, Adobe Flash, or Microsoft Word.”

Not only are the conclusions of the article inaccurate, it paints a negative portrayal of software engineers that isn’t grounded in reality. For starters, there is a distinction between “bad” software and “buggy” software. Software that is bad tends to be a result of poor usability design. Buggy software, on the other hand, is a consequence of a variety of factors stemming from the complexity of modern software. The largest factor in reducing the number of bugs isn’t going to come from improving the skills of individual programmers, but rather, from instituting quality control processes throughout the software engineering lifecycle.

Bad Software

Bad software is software that, for whatever reason, does not meet the expectation of users. Software is supposed to make our lives simpler by crunching data faster, or automating repetitive tasks. Great software is beautiful, simple, and, given some input from a user, produces correct output using a reasonable amount of resources. When we say software is bad, we mean any combination of things: it’s not easy to use. It gives us the wrong output. It uses resources poorly. It doesn’t always run. It doesn’t do the right thing. Bugs contribute to a poor user experience, but are not the sole culprit for the negative experiences that users have with software. Let’s take one of the examples Meisler has cited: Windows Vista. A quick search for “why does windows vista suck” in Google turns up these pages:


Oh, bugs are on there, and they’re pretty serious. We’ll get to that. But what else makes Windows Vista suck, according to those sites? Overly aggressive security prompts. Overly complex menus (we’ll visit the idea of complexity again later, I promise). None of the menus make sense. Changed network interface. Widgets that are too small to be usable shipping with the system. Rearranged menus. Search that only works on 3 folders. Those last few things aren’t bugs, they’re usability problems. The software underneath is, for the most part, what we software engineers call working as intended. Some specification somewhere designed those features to work that way, and the job of the software engineers is, in many companies, to build the software to that specification, as ridiculous as the specification is. One of my coworkers points out that Alan Cooper, creator of Visual Basic, wrote a great book about this subject titled, “The Inmates are Running The Asylum”. Interestingly enough, his argument is that overly technical people are harmful when they design user interactions, and this results in panels like the Windows Vista search box with fifty different options. But, to be fair, even when user interactions are designed well, just making the software do what the user expects is hard. A simple button might be hiding lots of complex interactions underneath the hood to make the software easy to use. The hilarious and often insightful Steve Yegge, talks about just that in a tangentially related post about complexity in software requirements. Software is generally called “bad” when it does not do what the user expects, and this is something that is really hard to get right.

Buggy Software

Buggy software, on the other hand, is software that does not behave as the software engineer expects or the specification dictates. This is in stark contrast to bad software, which is software that does not behave as the way a user expects. There’s often overlap. A trivial example: let’s suppose an engineer writes a tip calculator for mobile phones that allows a user to enter a dollar amount, and press a “calculate” button, which then causes the application to output 15% of the original bill amount on the screen. Let’s say a user uses the application, enters $100, and presses calculate. The amount that comes out is $1500. That’s not 15%! Or – the user presses calculate, and the application crashes. The user expects $15, but gets $1500. Or no result, because the application ends before it presents output.

Software is buggy partially because of bad documentation, as Meisler asserts, but not primarily because of it. Software isn’t even buggy because programmers can’t express “complex thoughts”, another of Meisler’s gems; all of programming is the ability to “combine simple ideas into compound ideas”. Software is buggy because of problems stemming out of complexity.

All software is built on top of abstractions. That is, someone else is responsible for abstracting away the details such that a programmer does not need to fully understand another system to be able to use it. As a programmer, I do not need to understand how my operating system communicates with the hard drive to save a file, or how my hard disk manages its read/write heads. I don’t need to write code that says, “move the write head” – I write code that says, “write this data to a file to this directory”.  Or maybe I just say, “just save this data” and never worry about files or directories. Abstractions in software are kind of like the organizational structure of a large company. The CEO of a large car manufacturer talks to the executive board about the general direction of the company. The executive staff then break these tasks down into more specific focus area goals for their directors, who then break these tasks into divisional goals for the managers, who then break these tasks into team goals and tasks for the individual employees that actually build, design, test, market, and sell the damn things. To make this more convoluted, it’s not all from top to bottom communication, either. There are plenty of cross team interactions, and interactions between layers of management that cross the chain of command.

To say that poor documentation is the primary source of bugs is laughable. Documentation exists to try to make sense of the complexity, but there is no way documentation can be comprehensible in any reasonably complex software with layers of abstraction, because, as Joel Spolsky, founder of Fog Creek Software says, abstractions leak. Programmers cannot know all the different ways abstractions they are depending on will fail, and thus, they cannot possibly report or handle all the different ways the abstraction they are working on will fail. More importantly: programmers cannot know how every possible combination of abstractions they are depending on will produce subtly incorrect results that result in more and more warped results up the abstraction stack. It’s like the butterfly effect.  By the time a bug surfaces, a programmer needs to chase it all the way down the rabbit hole, often into code he does not understand.  Documentation helps, but no programmer reads documentation all the way down to the bottom of the stack before he writes code. It’s not commercially feasible for programmers to do this and retain all the information a priori. Non-trivial software is complex as hell underneath the hood, and it doesn’t help that even seemingly simple software often has to turn water into wine just to try to do what a user expects.

Software engineers and critical thinking

I don’t deny the importance of writing or critical thinking skills. They are crucial. I wouldn’t be surprised if the same ability to reason through complex thoughts allows people to write well as well as program well. But to assert that writing skills lead to reasoning skills? This is a case of placing the cart before the horse. Meisler is dismissive of the intellectual dexterity needed to write programs:

“Most programmers are self-taught and meet the minimum requirement for writing code — the ability to count to eight”

It’s not true. Programming often involves visualizing very abstract data structures, multivariate inputs/outputs, dealing with non-deterministic behavior, and simulating the concurrent interactions between several moving parts in your mind. When I am programming, holding in my mental buffer the state of several objects and context switching several times a second to try to understand how a small change I make in one place will ripple outwards. I do this hundreds of times a session. It’s a near trance-like state that takes me some time to get into before I am working at full speed, and why programming is so damned hard. It’s why I can’t be interrupted and need a contiguous block of time to be fully effective on what Paul Graham calls the maker’s schedule. I’m not the only one who feels this way – many other programmers report experiencing the mental state that psychologists refer to as “flow” when they are performing at their best. 

How to reduce the incidences of bugs

Phillipe Beaudoin, a coworker, writes:

I like to express the inherent complexity of deep software stacks with an analogy, saying that software today is more like biology than mathematics. Debugging a piece of software is more like an episode of House than a clip from A Beautiful Mind. Building great software is about having both good bug prevention processes (code reviews, tests, documentation, etc.) as well as good bug correction processes (monitoring practices, debugging tools).

Trying to find a single underlying cause to buggy software is as preposterous as saying there is a single medical practice that would solve all of earth’s health problems.

Well said.

I’m disappointed in the linkbait title, oversimplification, and broad sweeping generalizations of Bernard Meisler’s article. I’m disappointed that this is how software engineering is being represented to a mainstream, non-techie audience. It’s ironic that the article totes writing skills, but is poorly structured in arguing a point. It seems to conclude that writing skills are the reason code is buggy. No wait – critical thinking. Ah! Nope, surprise, writing skills, and a Steve Jobs quote that is used in a misleading way and taken out of context mixed in for good measure. He argues for the logic of language, but as many of us who also write for fun and profit know, human language is fraught with ambiguity and there’s a lot less similarity between prose and computer programming languages than Meisler would have the mainstream audience believe. I’m sorry, Herr Meisler, but if your article were a computer program, it simply wouldn’t compile.

— Ikai

Written with special thanks to Philippe Beaudoin, Marvin Gouw, Alejandro Crosa, and Tansy Woan.

Written by Ikai Lan

October 9, 2012 at 11:14 pm

12 Responses

Subscribe to comments with RSS.

  1. Maybe you’re lucky because you’ve only worked at Google and other places like that, but I’ve met some coders who were real duds – people who went into programming because their mamma told them it would be a good career choice. I’ve also met some amazing programmers who could keep the whole world in their heads and see every consequence of every decision. If there is any correlation with self-taught-ness, it’s that the duds all had degrees in computer science, because that’s the only way they’d get hired. Some of the amazing ones had degrees in computer science, and some were self taught, because the only way you could have kept them from learning about computers would be to lock them in a cave. I don’t know if it’s correlation of causation, but if you’re a great programmer (and I like to think I am), you go home from working with computers all days and you tinker with computers.

    Paul Tomblin

    October 10, 2012 at 3:11 am

  2. You’re very smart, work for Google and are fairly young, so I suspect you haven’t experienced a vast swathe of mediocrity. I see this pattern a lot: someone posts about bad coders, a swarm of good coders indignantly reply the claims don’t apply to them.

    OTOH, I suspect the actual problem is that bad coding and bad writing are both symptoms of bad and unclear thinking. So teaching writing won’t fix the problem, which is the oceans of mediocre thinking out in the big world.


    October 10, 2012 at 3:23 am

  3. I couldn’t agree more. The Atlantic should really publish this response to make up for the embarrassment of the original essay.

    Oh, and you misspelled poor Philippe’s last name up there :)

    Joel Webber

    October 10, 2012 at 5:34 am

  4. I suppose next you’re going to say bad things about my brilliant plan to disband engineering and hand all coding duties over to the technical writing department.

    Larry Hosken

    October 10, 2012 at 6:39 am

  5. David,

    I work in Developer Relations. 90% of my time is spent teaching and advocating to developers outside Google. I have met all kinds of developers. I have met brilliant ones, great ones, average ones, and below average ones. I have worked with all of them. The original post in The Atlantic is irresponsible because it casts a poor light on all software engineers. I mean, can’t you make the argument, “the reason industry X has problems is because most people in it are mediocre” to any industry? That’s taking the easy way out. It’s true that hiring bad software engineers adds some additional cost to the entire software development cycle – more time is needed in process. It’s been said that software engineering is a 10x industry. I believe this is because of the butterfly effect, and yes, hiring bad software engineers can have a 10x cost effect in the other direction.

    I don’t claim that what he says doesn’t apply to me. I’ve written my fair share of horrible code and horrible documentation. I just claim that the right process that does not add to much overhead, yet is comprehensive, is the solution. I don’t get to skip process.

    Ikai Lan

    October 10, 2012 at 6:52 am

  6. It seems like everyone reading this article seems to carry some emotional baggage from working with bad developers, and seem to miss the point that reducing bugs is about process. Bad developers add to the cost of process, but it’s because writing software is hard because software is complex. Teaching writing skills won’t make those teams perform significantly better.

    Ikai Lan

    October 10, 2012 at 6:54 am

  7. And my first name too, but it’s all fine now. Ah, those darn communication skills. ;)

    Philippe Beaudoin

    October 10, 2012 at 10:47 am

  8. Ah, no, the first name is still wrong. ;)

    Philippe Beaudoin

    October 10, 2012 at 10:50 am

  9. Hello Ikai. I left a detailed rebuttal to your rebuttal over on the Atlantic site. But I’d like to state a few things here, first and foremost that I think you missed the point of my article – after reading your final sentence above, I’m pretty sure you didn’t read the original article that I wrote my piece in support of – http://www.theatlantic.com/magazine/archive/2012/10/the-writing-revolution/309090/. Teaching writing skills in an underperforming school in NYC – even in science and math classes – was found to result in a huge increase in test scores and a much lower drop-out rate.

    Yes, writing software is complex – but writing decent documentation – whether that be in the form of unit tests, self-documenting code, good API documentation or user manuals – is hard, which is probably why it is so rare. And you’re right, I did unfairly single out engineers – but I did that because I’m an engineer, and I didn’t want to muddy the waters for a non-technical audience by dragging product managers, project managers, UX designers and QA into the mix – although they’re at least as much to blame for all the bad – frustrating, confusing, hard to learn, hard to use – software out there. Google is as guilty as anybody else – here’s an example of badly written and poorly organized API documentation off the top of my head: https://developers.google.com/doubleclick-advertisers/docs/overview.

    FWIW, I didn’t write either the headline or the subtitle, or even get the chance to approve them.

    Finally, your solution of more process makes my blood run cold…the industry needs better communication skills, not more process.

    And what’s with the “Herr Meisler” bit? Bordering on an ad hominem attack, aren’t we?

    Bernard Meisler

    October 10, 2012 at 9:19 pm

  10. I did read the original article, but it supports a point that I don’t agree with. In my post I stated that improving the individual performance of programmers was going to be less impactful than improving software project management.

    Again, not sure why you’re picking on Google. I don’t think I ever claimed all Google software was great, or perfect, or even close.

    I never said more process. I said good process. Good process shouldn’t feel like process. Good process should feel like the right things to do. Again, your examples of unit tests, code review (to verify that code can be read easily), and shipping comprehensive API documentation as a primary milestone instead of an afterthought are all part of what’s considered process.

    You’re imagining things re: “Herr Meisler.” It just sounded the best out of my choices at the time (also … I’m not sure what kind of ad hominem attack it would be to imply a Germanic link). Unless you are referring to my criticism of how the article was poor structured. It wasn’t just me, by the way. I sanity checked it with a few folks, not all in tech, just to make sure I wasn’t imagining things. That’s not an ad hominem attack. That’s pointing out the irony of an article about improving writing skills that, even if I agreed with the content, could have gone through a few more rounds of review before publication.

    Ikai Lan

    October 10, 2012 at 10:18 pm

  11. I am said to see documentation being so dissed. I agree it’s not the most important way to combat bugs, and I agree that it’s ironic for an article about writing skills to be poorly organized. At the same time, I find documentation tends to be underemphasized by developers that are new to programming in the large.

    In my experience, bad documentation is a sign that the software component itself is poorly thought out. The code is not just harder to learn–the code is just plain bad. The abstractions don’t just leak; they are internally contradictory, or sometimes not present at all. It’s just a mass of code that does whatever it does.

    Documentation does more than “try to make sense of the complexity”. It also makes the complexity more sensible. Any time a library, tool, format, or language is going to live beyond a throw-away demo, it behooves the developer to document it before slinging a lot of code. It shouldn’t take long, and often the act of documentation will lead to insight on how to make the software simpler to begin with.

    Lex Spoon

    October 12, 2012 at 9:15 am

  12. Ikai, I’m late to this discussion, but just posted something rather long at The Atlantic…

    I actually teach technical writing to engineers. In the first place, you are absolutely correct to focus on process to reduce bugs, while focusing on users is the path to making software that is “good”.

    I would like to suggest that most engineers need to be taught techniques of empathy, like Cooper describes in building user personas. Once the engineers have a better understanding of the needs of the users, the software will be better.

    Since it’s a team effort, describing these user needs and sharing the goals you have discovered so they are understood in a consistent way across the organization is a real challenge.

    I think you can meet this challenge by using standard writing conventions, starting with:

    1. Present tense
    2. Active voice
    3. 2nd person

    Universities teach the opposite. They teach you to avoid the 2nd person, while every academic textbook is a relentless amalgamation of passive sentences using every tense but the present. You’r told to write “at least ten pages” or some other arbitrary length, rather than taught how to write succinctly.

    Going back to the university to take a writing course won’t help. The literary writing instructors rarely know much about technical writing style. I now teach customized writing courses for technology companies in Europe that recognize how valuable it is to communicate clearly, and don’t want to waste their time learning the wrong tools for describing technical subjects.

    http://www.williamstechnical.eu (some short video lectures if you are interested)

    To support the processes a mature company uses the engineers and managers must use the same language. The colleges and universities aren’t teaching that language.

    Fortunately, it’s not too difficult to learn. When engineers who have been afraid to write documentation learn it’s not so difficult as they feared, the processes really improve. When technology oriented people learn more about the user, even if it’s a fictitious persona, the increase in empathy brings dramatic improvements in the user interface.

    So I think there’s hope…as universities and colleges pick up on how important technical communication can be for the students’ futures, they’ll put me out of business by including this in the writing curriculum.

    Until then, let me know if you want me to pay your company a visit. :-)


    Fred Williams
    Williams Technical

    Fred Williams

    October 27, 2012 at 9:22 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s