I made a heartbreaking discovery last night. I've been working on a new release of dcdflib, with significant rearrangement of several routines to remove labels and goto statments. I had been performing limited testing and I was also checking in often. It's a slow process, it's easy to make a mistake and when you're tired, shortcuts are tempting. I took a testing shortcut after modifying beta_rcomp. I only tested a couple of subroutines in the demonstration program, thinking I had covered all routes that depended on beta_rcomp. I missed a dependency.

I was in the process of cleaning up the code when I ran a complete test set in order to review the entire output.  Right off the bat, I noticed two errors in routines I knew I had not touched. A little manual checking and I saw the dependency to the function beta_frac, which calls beta_rcomp. Drat.

Fortunately, I was able to review the source check-ins and located the problem. I was able to paste in the unchanged version of beta_rcomp and the program produced the proper output. beta_rcomp is fairly complex, and it was disappointing to lose my changes.

The moral of this story is:

Don't skimp or shortcut your testing and check in your source code often. I could have lost several days worth of changes with this bug. Instead, I only lost one routine, which I should be able to trace through and repair.

Update

Even if you are working on public code, you need to have a test plan. It's hard to maintain discipline 100% of the time, but you still need a plan. When things go a little wrong, like they did for me, the plan can help you get back on track.

You also need to check in often. I can't tell you how much more secure you will be in changing your source code if you practice good version control technique. I always check in after a full test. I don't like going days without checking in. It takes time, but it also enables other people using your software to trust your work more than if you are just cowboy coding.