Writing Code Isn’t Rocket Science (It’s Worse Than That)

Today, an old joke:

Q: What do rocket scientists say when they want to describe a portion of their work as easy?
A: “This bit isn’t exactly brain surgery.”

I think that pretty much everyone would agree that rocket science and brain surgery are both intellectually demanding pursuits. But it seems to me that there’s a fundamental qualitative difference between them. 

Rockets are devices constructed by humans for specific purposes. Though there may be considerable systemic interactions between all the parts of a rocket which must work harmoniously together, those interactions are the result of careful design. The rocket as a whole can be decomposed into its original parts, and those parts can be independently tested to see if they meet their design criteria.

Furthermore, the aim of rocket science is usually to deliver a specific payload to a specific place at a specific time.  Though it is no mean feat to get to the moon, we can least for all practical purposes calculate the future position of the moon at any time you care to name to any degree of precision.

And yes, it’s hard, and yes, mistakes are made, sometimes with tragic consequences.  But fundamentally, rocket science is about shaping raw matter into precise forms to achieve precise tasks.

Brain surgery isn’t nearly so much like that.  We’re presented with a lump of thinking, dreaming meat that we barely understand how it works and is presently being used to solve all manner of problems that evolution did not design it for. Our understanding of brains is strongest at the very low level – the neurochemical level – and at the very high level – the gross divisions of the brain into the centers that control particular muscles, responses, etc. But we have practically no understanding whatsoever of any level between those – we are no where close to understanding what algorithms the brain uses to recognize faces or write music.  And a working, living brain has trillions of interacting parts which were not designed with orthogonality or functional decomposition in mind. 

I’ve been thinking about the difference between brain surgery and rocket science lately in the context of my coworker Peter Hallam’s essay on the difference between writing new code and modifying old code.

Naively, one would think that adding new features to code would be like rocket science.  You understand all the parts, you figure out how to redesign the parts to admit the new desired behaviour, you implement it, test it, and you’re done.  It’s an intellectual challenge, but it’s fundamentally amenable to analysis because every part has a clear, well-designed function that can be tested independently.

But as Peter points out, anyone who has actually tried to add major new functionality to existing code knows that most of the time its more like brain surgery.  We know what the code does on a gross level.  (Say, tokenize source, parse, create symbol tables, bind type annotations, check reachability, generate code.)  We know what any part of it does on the microscopic level. (Say, move the contents of this register to that memory location.)  The hard part is understanding what the algorithms are that make up the large-scale behaviour, and understanding how to tweak them to admit the new desired behaviour without breaking anything.  (How does tweaking early nullable realization during binding affect rewriting lambdas into expression trees?  Who knows?  Not me, that’s for sure!)  Understanding all that stuff is the incredibly hard part; actually putting the code under the knife is comparatively trivial.

A big part of good implementation of software-in-the-large is making sure that the program is more like a rocket than a brain.  Coming up with tools to enable that admirable goal is the hard part. 

Comments (21)

  1. DrPizza says:

    Please can you put complete absolute links into posts instead of server-relative ones?

    That way I can click them straight from Outlook (through RSS Popper) rather than having to visit this web page.

  2. EricLippert says:

    No, apparently I cannot.  When I try to, the blog software automatically corrects it to a relative link.  Complain to the people who wrote the blog software — I have no control over it.

  3. Dave says:

    Just FYI, my version of RSSPopper (0.35c on Outlook 2003) seems to handle relative links fine.

  4. Darth Cragar says:

    The engineering-vs-brain-surgery distinction you’re making <a href="http://en.wikipedia.org/wiki/Synthetic_proposition">sounds semi-familiar</a>, doesn’t it?

  5. Darth Cragar says:

    P.S. <a href="http://www.google.com/reader">Google Reader</a> turns the relative path to absolute. Correctly, I mean.

  6. Darth Cragar says:



    Comment preview would be a nice feature.

  7. EricLippert says:

    As I said above, I do not control the blog software.  Take it up with the people who wrote the software if you want new features.

    I am aware of what the differences are between synthetic and analytic propositions, but I have no idea how you’re relating them to the difference between brain surgery and rocket science.  

  8. barrkel says:

    Interesting. It’s been clear to me, from modifying code someone else wrote, that you end up making mistakes trying to implement something, all the while zeroing in on the Gestalt of the programmer who wrote it.

    I personally refer to this as the difference between knowing something and it being part of you. When you know something, you can recite its properties, and perhaps you can describe it recognizably to someone else. So, you can understand how a program works on a high level. But making modifications to that program requires that you have a model of the whole program in your mind at the same or close semantic level as the original author, or otherwise you leave yourself open to unintended consequences as unrelated parts of the code start to conflict in ways you didn’t imagine in your imperfect understanding of the code.

    As I program, I’m always thinking of the different processes / threads / callstacks that can be happening before or after or in parallel with the code I’m currently writing. These little "daemons", imaginary threads running in my imagination, help me write correct code. It’s only when you truly understand the code that you can build these little daemons.

    I think its this process model, a flow that is currently or potentially in action, that provides the link between the atomic minutia and the global continents of understanding, whether in the brain/mind or in code. It seems that we do not have a lexicon or calculus or commonly used notation for this process model or its components, probably because our brains would interpret such a lexicon as just more atomic data or continental data, and not what is – the missing link. It would have to enter the brain through the knowledge route, but you don’t get the "daemons" without practice. Doing becomes.

  9. robertsconley says:

    Actually Rocket Science is like brain surgery because of rocket engine. Basically a rocket engine is a chamber attached to a nozzle. Attach to the chamber are pumps and fuel lines that mix the fuel in an attempt to get nice even combustion.

    The biggest problem of rocket science is getting that nice even combustion. Combustion instability is a big problem to solve for new engines and why rocket engineering is so hard. :ike software development it is more art than scinece. It is also the reason that you have to test your rocket before committing to regular operation.

    Sorry to puncture your analogy and I understand what you were getting at.

  10. Isabelle (Rocket Scientist) says:

    And this is exactly why I’m not a good coder.  

    I have to agree with what Eric said about coding.  No matter how much I understand each component, it seems that there is always a fundamental something that I’m missing to make it work well.

    (and kudos to those who can code well.)

    I’ll go back to tinkering with my rockets. 🙂

  11. LarryOsterman says:

    And of course there’s the software archaeology aspect of understanding old code: http://blogs.msdn.com/larryosterman/archive/2004/05/20/135952.aspx

    There are code bases out there that have been worked and tweaked so often that it is often impossible to actually fully understand them, no matter how long you’ve been working on them.

  12. junxter says:

    Perhaps a more apt distinction can be drawn between, say, brain surgery and designing a mechanical watch?

  13. Last Post today: Three good reads!
    1) Peter Hallam from Microsoft, pointing out the important thing of a good IDE. He starts with the experience that developers spend 2-5% of their time in writing new Code, 20-25% in modifying existing Code and the rest

  14. Zara says:

    Brain surgery is just highly advanced plumbing.  It’s neuro-modeling you’re talking about with regards to the way a lump of thinking meat writes music.

  15. Nat says:

    So you are saying rocket science isn’t exactly brain surgery?

  16. Rocket Science 7 brain surgery? says:

    Nhlanhla Mlitwa

    Obviously the complexity suits the proprietorship and the protectionist aspect. I make business out of it I ould not complain. From the open source perspective, can we not make deliberate efforts to to make code modifications more simpler? Is this a worthwhile route?, what are implications for hacking?.

  17. Nhlanhla Mlitwa says:

    Obviously the complexity suits the proprietorship and the protectionist aspect. I make business out of it I ould not complain. From the open source perspective, can we not make deliberate efforts to to make code modifications more simpler? Is this a worthwhile route?, what are implications for hacking?.