07. January 2011 · 7 comments · Categories: humour

It would be very easy to re-post pretty much everything from xkcd, and I’m trying hard to resist, but this is just too delicious to let pass, as it explains perfectly the dilemma of  code quality in climate models (and is much shorter than my “Do Over or Make Do” talk):

Good Code

...oh, and that reminds me to grab the link to that one about how obnoxious physicists are when encountering a new subject.

The Affordances of Bike Lanes
Headline Spin

7 Comments

  1. Do not forget telling the client
    You can have ABC (easy) or DEF (hard) and get back
    Great; we will have ABFZ (not remotely possible)

  2. How and why do requirements change while scientists work on some part of a climate model? Don’t they manage their requirements themselves?
    (Also the “throw it all out and start over” part is not possible for large chunks of a legacy system, usually. If a software project lives long enough, it’s more like “give up and find a way to live with it”.)

  3. Tim: Requirements for climate models change all the time: new science, new data sources, new computing platforms, new kinds of runs & outputs requested by the IPCC….
    To give one example of the latter, consider that most modeling labs started their runs for the current IPCC assessment last summer. Now look at how often the requested outputs have changed over the last six months:
    http://cmip-pcmdi.llnl.gov/cmip5/output_req.html

    Anyway, you’re right about the “find a way to live with it” part.

  4. Ah, so thats what the Cloud(tm) is for. Its where good code comes from .

  5. Nick Barnes :
    Re “throw it out and start over”, see http://www.joelonsoftware.com/articles/fog0000000069.html

    While I agree with everything in the text itself I very much disagree with one of the headlines: “It’s harder to read code than to write it.”
    No, it does not have to be this way, it is actually possible to write code that is easier to read and understand than to rewrite. Really. There are several books on the market that explain some howtos, if you don’t happen to know a local code guru.

  6. Joel is, of course, a “local code guru”. Well, not so local. So am I, in my own way, and have spent most of the last twenty years specifically working on making it easier to read code (e.g. by developing implementations of easy-to-read languages, by creating and applying coding standards to ensure that a given body of code is easy-to-read, and by systematically rewriting pieces of code with a focus on clarity).
    But Joel’s point, I think, is that the urge to rewrite stems in part from the identity of many programmers as *programmers*: we enjoy writing code, much more than we enjoy putting in the hours to understand the complexity of some existing code. Although most code is more complex than it needs to be, even a good body of code will often have an irreducible complexity which is No Fun to grok. Part of being a professional is biting this bullet.

Join the discussion: