I am the lone software engineer on a team that develops physics models (approx 30,000 lines of code). The rest of the team consists of scientists who have been developing their codebases for about 20 years. My workflow goes something like this:
- Scientist requests a new feature
- I implement it
- Via testing & validation, I find a serious problem somewhere deep within the numerics
- Scientist requests a new feature (without fixing the problems identified in #3)
Our problem seems to be that bug tracking is done via e-mail and post-it notes. Busy work schedules let bugs slip under the radar for months and months. I think some formalized bug tracker (i.e. Trac, Redmine, Jira, FogBugz, etc.) could help us. The following features are essential:
- Incredibly easy to use
- Integrate with version control software (we use Subversion)
There are plenty of posts that suggest which bugtracker is "best"… but I suppose that I am more interested in:
- What's your experience in whether or not the overhead of a bugtracker is worth it
- How do you convince a physicist (who follows poor software engineering "best practices" from the 70's) that a bug tracker is worth the extra effor?
- I get the feeling that if I install a bug tracker, I'll be the sole user. Has anyone else experienced this? Is it still useful? It seems like the team would need a certain amount of "buy-in" to make a bug tracker worth the additional overhead.
Best Answer
I suggest taking a look at Strategy 2 in this Joel On Software article. He basically argues that if your company doesn't use bug tracking software, you should just start using it for yourself, and demonstrate how it helps get things done. Also ask other people to use it to submit bugs so they see how easy it is to use.