Last night I was running some code for a queuing simulation related to some research I'm doing. This is the Nth time I've used this code; I wrote up the basic simulator back in grad school for some of my thesis work (on the power of two choices), and every once in a couple years or so, some project pops up where what I want is some variant of it. So I copy whatever version is lying around, tweak it for the new problem, and off I go.
Today when I was putting together the table the numbers just didn't look right to me. I re-checked the theory and it was clearly telling me that output X should be less than output Y, but that wasn't how the numbers were coming out. Something was wrong somewhere.
After staring at the code a while, and running a few unhelpful tests, I decided to go back to square 1, and just run the code in the "old" configuration, where I knew exactly what I should get. And I didn't get it.
That helped tell me where to look. Sure enough, a couple minutes later, I found the "bad" line of code; last project, I must have wanted to look at queues with constant service times instead of exponential service times, and I had just changed that line; now I needed it changed back. And all is well with the world again.
I'm sure there are some lessons in there somewhere -- about documenting code, about setting things up as parameters instead of hard-wiring things in, all that good stuff one should do but doesn't always. It catches up to you sooner or later. Meanwhile, the code is back to running, and in about 24 hours I'll hopefully have the table I need.
Subscribe to:
Post Comments (Atom)
7 comments:
For some reason this reminds me of the graphics code that had run a hundred times successfully on the PDP-1 in 1968 but failed when the ARPA site visitors arrived. We recompiled it from a saved copy of the source and it compiled without any error messages but it still crapped out almost immediately when we ran it. After the visitors left the problem was uncovered. The PDP-1 was built without a division instruction, but with a "divide step" instruction that could be iterated in software. Divide was a field mod using the same op code, and there was a DIS/DIV toggle switch inside one of the bays so you could run legacy code. The compiler did no divisions, apparently! Happy New Year and may all your simulations be bright.
Fascinating! Happy new year, dinosaurs!
@Anonymous: I don't know if you meant it as a joke or sarcasm. In any case, both of these guys can eat you for breakfast.
I have this similar problem every now and then. I guess every programmers have it at least once :) I am using automatic unit test now. 20% unit tests uncover 80% of the problem.
Couldn't agree more, #4. Write unit tests for as many lines of code as you can.
Couldn't agree more, #4. Write unit tests for everything you can.
Version control! Things like git are quite simple to set up and use. Each time you finish a new project, check the whole thing in with a brief comment.
Post a Comment