Common practices that scientists don’t use when writing code, and why we should

February 11th, 2008 by jose

Do you need to write code in your academic work? Have you read someone else’s code? Did you just get  a code attachment with a warning like “this is a mess, I need to clean this up someday?”. Well, you are not alone. It seems that in the industry, telling someone that you plan to use code that comes straight from an academic makes them feel a drop of cold sweat down their backs.

American scientist has an article on these common practices that we have managed to avoid for so long.

I therefore started asking scientists how they wrote their programs. The answers were sobering. Whereas a few knew more than most of the commercial software developers I’d worked with, the overwhelming majority were still using ancient text editors like Vi and Notepad, sharing files with colleagues by emailing them around and testing by, well, actually, not testing their programs systematically at all.

I finally asked a friend who was pursuing a doctorate in particle physics why he insisted on doing everything the hard way. Why not use an integrated development environment with a symbolic debugger? Why not write unit tests? Why not use a version-control system? His answer was, “What’s a version-control system?”

The paper advocates the use of version-control, proper editors and IDEs, and unit testing. These three things are great practices, and in my experience we academics either don’t use them or had to learn them ‘on-the-wild’ after banging our heads on a wall. And it shows.

Our code could be tidier. The bad news is that this reputation seems not to be restricted to code tidiness.

The unqualified-reservations blog has a (long) post on how CS research in the academia is considered outside:

…anyone who’s not involved in CS research treats the products of this endeavor as if they were smallpox-infected blankets. Even when it is clearly – in my opinion – good, it winds up ignored. Because of the inescapable grant-related propaganda, it’s impossible to tell what’s good and what’s not.

The gist of his main point is that usefulness and relevance are almost inversely related to academic value. That gives academics the ‘freedom’ to write unmanageable code; as long as it produces a paper (and note that code is not provided with the paper) you are fine. A caricature: a guy invents a programming language (say python) that is used by millions included google. It has zero academic value. Another guy writes and obscure paper (or hundreds) on a topic that is irrelevant even to his mom. That second guy gets grant money, tenure. Sounds familiar?

If you enjoyed this post, make sure you !


8 Responses to “Common practices that scientists don’t use when writing code, and why we should”

  1. DotMGNo Gravatar Says:

    I’m writing all my codes with Vim.

    Q: Why not use an integrated development environment with a symbolic debugger?
    A: I use Vim because it is (AFAIK) the only editor that let me work without the need of a mouse. I hate mouse: it slows me:
    https://academicproductivity.com/blog/2006/why-slickrun-is-the-best-thing-in-the-world-ever/
    I invested time learning how to use it, and I’ll continue to use it because actually, I write faster with Vim than with any other editor. I’ve tried Eclipse, but, I think, it’s the kind of software that you love or you don’t love.

    Q: Why not write unit tests?
    A: What are unit tests?

    Q: Why not use a version-control system?
    A: Actually I do, and it’s great.

  2. locaNo Gravatar Says:

    erm, why should the Python-inventing person even get compared to academics? academic life is a world of its own and does not speak to other kinds of merit. just as the european ice-dancing championship judging criteria is irrelevant to most academics (our careers at least), peer-reviewed pubs, grants, and tenure are irrelevant to most non-academics.

    what’s the argument in this post? sure, code can be written more professionally — but i have another profession, which is to be a researcher. is there a real compelling argument that writing non-messy, more professional code is going to make my research better? if it simply means professional programmer will dread my code and make fun of me, seriously, who cares? here i am making fun of those ice skaters’ outfits or something and i am sure they don’t care…

  3. adminNo Gravatar Says:


    I use vim too, for the same reasons.
    Using an IDE was the point of the original article, that I don’t particularly share.

    ,
    Yes, but bad code affect researchers too! I have had requests for sources, and I had to answer “sorry, it’s in such a mess that I doubt it’d be useful for you.” And I had this same answer given to me by two researchers friends about their code just in the last month!

    Plus, if the people who can apply basic research don’t because they fear the code, society overall would improve a lot slower (i.e., applied people who don’t read papers and even less academic code are condemned to reinvent the wheel).

    The last argument about doing something that people actually use is very well presented in that unqualified-reservations blog post (but long! :) )

  4. kdNo Gravatar Says:

    I use emacs as my ide and code in perl and R. IDEs are there to compensate for an absence of decent command line tools.

    As far as test driven development goes … well … I found a bug in an open source web framework, the maintainer asked me to go and write some tests to illustrate the bug which I did, and immediately saw the value.

    Mind you for my day to day coding needs, 99% of what I do are one-shot scripts where tests are more trouble than they’re worth.

  5. whudajokeNo Gravatar Says:

    “Use an IDE”???!!?!?!?

    Seriously, /THAT/ is supposed to make us write better code?

    I’ve spent lots of time with various IDEs over the years in a number of industry jobs, and found one pattern that keeps repeating itself: noobs and guys that aren’t very good at coding rely heavily on IDEs, while the guys who are /REALLY, REALLY GOOD/ at what they do invariably prefer vi or emacs.

    Whoever it is you are quoting that thinks IDEs should be a fundamental part of “best practices” just lost all credibility.

  6. joseNo Gravatar Says:

    Well, another trend according to reddit is that guys who use vim or emacs don’t have girlfriends :)

    But seriously… Are there any stats that prove that IDE-guys are worse programmers? Maybe IDE-guys just use less productive languages (java) versus script languages for the vim/emacs crowd?

    On the other hand, those who use run-off-the-mill editors (read:easier than vim/emacs) don’t strike me as tremendously productive either. But my sample is pretty small. It does make sense that the hardcore programmers would gravitate towards hardcore editors. But I must admit that some situations (e.g., rails development) are just better suited towards IDEs (e.g., find usages, find definitions).

  7. Anonymous Says:

    Any evidence that IDEs, version control, and unit testing actually result in better code?

  8. joseNo Gravatar Says:

    The problem here is: how do we measure code quality? and programmer productivity?

    Looks like those are open problems.
    Number of commits, lines of code, etc are all bad proxies (you can crank out code really fast but make it so bad that people have to go repairing what you touched :) ).

    I found this post interesting:
    http://www.webfoot.com/blog/2006/12/17/programmer-productivity-part-3/

Leave a Reply