Maintaining code for other people sucks

Perhaps I might not be the best programmer in the world, but I can do enough to get things done. Last month, I managed to write a macro that does fitting for measurement curves to extract system parameters for some devices we are making.

We've got a production line going making devices that needed some assistance for device characterization, so I decided to pitch in and write a program that does the fitting for them. It took about a week to write, test, debug and install into the factory line and things were going great until I got an e-mail this week saying that the program wasn't working well. It turns out that the new batch of devices that are being fabricated have characteristics that make it hard to fit nicely and the mathematical functions that is used to fit the data against is somewhat unstable under certain conditions that causes it to blow up, meaning that the solver that comes pre-equipped in Microsoft Excel runs into a brick wall when the function blows up on it.

I've decided to write a new solver to deal with the problem and I need to go through the entire writing, testing and debugging phase again to add in this new module. As a result, I am not particularly happy with this predicament as it sucks up time from me doing anything else.

So I'll say that I've learned a valuable lesson here: I've written useful code for someone else that doesn't know how to maintain it, resulting in me having to keep track of things when conditions change or when things go wrong. The code doesn't benefit me and it costs me time in after care. Perhaps learning about code after care is important as well, but I would much rather maintain code that is a direct benefit to me; like dealing with 2 birds with one stone. In this case, it's my stone being used to hunt for someone else's bird.