Most of my published papers have been about software or have been made possible by software. But there's a big difference between a software project whose lifetime is measured in years and which supports a whole stream of papers, and a student's summer project that if lucky gets into one paper submission.
With that preamble, here are my responses to the Joel Test:
Do you use source control?
Always. Even for papers. Newer tools like git and darcs have made it easy compared to the bad old days of CVS and RCS.
The last project for which I didn't have source control from the start was noweb, which I started as a first-year grad student in 1989. It didn't get imported into source control until 1991. It formed the basis for one scientific paper.
Can you make a build in one step?
Yes for most projects, but often not until the project is several months old. And when software is going to be distributed or when I am collaborating with someone outside my institution, it gets harder.
When I am playing lone wolf it often is several months before I even know what I mean by a build.
When a project is mature, not only do we have a one-step build, we have a one-step build-and-run-regression-tests. Couldn't survive without it.
Do you make daily builds?
No. The one project I headed that made daily builds was Quick C--. The daily build server died two years ago, and we never found enough value from it to make it worth replacing.
I would make a daily build only for a big project with real users. At that point it's not likely to be "lone wolf" any more.
Do you have a bug database?
Usually not. There have been a couple of exceptions, but we've had a hard time finding a bug database that meets our needs as Linux users.
We'll be trying again soon with http://community.haskell.org.
Do you fix bugs before writing new code?
Sometimes. We get paid to make new discoveries, not to build working software. That said, the working software gets us credibility. But if the project is small enough that I am the only one working on it, I fix bugs only if they need to be fixed.
Do you have an up-to-date schedule?
Never. (Unless you count the next paper deadline.)
Do you have a spec?
Never.
Do programmers graduate students have quiet working conditions?
Yes.
Do you use the best tools money can buy?
No. Sadly, this decision doesn't impact us much, because great tools for Haskell or Lua or ML are generally not offered for sale. But when I worked on C compilers as a researcher, we could not afford to buy the Plum-Hall test suite.
Do you have testers?
No.
Do new candidates write code during their interview?
No. Graduate students are hired based on research potential. Postdocs are hired based on research achievement.
Do you do hallway usability testing?
Not nearly enough. But it's hard to grab someone in the hall and get them to try out your new language or your new code generator :-)
