This is inspired by Joel's
12 steps to better code:
http://www.joelonsoftware.com/articles/fog0000000043.html
Although we are high energy physicists, most of our time is spent writing code (in C or C++). So I thought it would be curious to see how we measure up to the best practices advocated by professional programmers.
- Do you use source control?
Yes. We have 3-4 people actively working on the code in Chicago and about 2 people in Italy, so version control was very useful. We started with CVS provided by ATLAS, and got upgraded along with everyone else to SVN in 2009.
- Can you make a build in one step?
Yes. We have a bash wrapper that sets up and builds the software in one step. However, some environment variables need to be set by the user. For developers / active users, this is not an issue, but newbies often have trouble.
- Do you make daily builds?
No. That would be useful, and some members of the team suggested it, but we never got around implementing it. As a matter of fact, we don't even have a set of robust test cases. I had committed a simple big-picture test a while ago, but it never caught up and is probably deprecated by now.
- Do you have a bug database?
No. But it would be very useful! I remember cases when bug fixing was delayed and sometimes forgotten altogether until someone else got hit by the same bug (superstrip map format, anyone?)
- Do you fix bugs before writing new code?
No. And that's a problem. In academia, we are often under pressure to produce results, even with buggy code. So we end up introducing temporary workarounds and forgetting about them...
- Do you have an up-to-date schedule?
Yes. We don't have a formal centralized schedule, but it is constantly brought up in weekly meetings (and thus kept in agenda pages), with specific tasks and approximate completion dates. Interestingly, the completion date estimates are almost always a factor of two shorter than what they end up being in practice.
No. But I don't think we could. New ideas pop up almost every week, so the spec document would be completely fluid. Effectively, we have that in the agenda pages for the weekly meetings.
- Do programmers have quiet working conditions?
No. We have offices, but we usually share them with another grad student. This results in frequent chatter about stuff unrelated to work, with the subsequent drop in productivity.
- Do you use the best tools money can buy?
Yes. Lucky us - we can get academic discounts on fancy electronics design software, or sometimes just get it for free. And the GNU compiler collection is free anyway - and it's very good!
Haha, testers in academia? On a more serious note, first-year grad students effectively act as testers before they learn enough to start coding new projects themselves.
- Do new candidates write code during their interview?
No, we are physicists after all, not programmers. Some people starting a Ph.D. in high energy physics don't even know how to close an emacs window and are completely clueless when the compiler throws an error message. But to be fair, most of us had quite a bit of coding experience before coming to grad school.
- Do you do hallway usability testing?
In a way, we do. A newly written feature often immediately gets into the hands of a beginning graduate student who will run it and report any problems or unexpected results.
