So, we have this service. It is a web application (and some associated bits and pieces) to let our users manage some server-side anti-spam settings, things like what level of (server-side) spam filtering they want, whether they'll accept greylisting (although we don't call it that), and so on. It works, it's been there for years, and it has one problem: for reasons beyond the scope of this entry, it's a black box with no maintainer.

(Actually that's a bit of an exaggeration. We know a bit about how it works and what's inside the box, enough to know that it's not ideally built and it's not how we'd do things today. This is one reason no one has devoted the time necessary to read and understand all of its code.)

For some time this has left me wrestling with the question of whether or not I should rewrite the service. On one side is the fact that the service fully works as it is now; it's functional and it doesn't need any attention, it just keeps on quietly going properly. On the other side is the fact it's a black box that we don't understand and can't do anything to. It's not a crucial service, but still, if it breaks during some software upgrade we've kind of got a problem.

(This has actually happened a time or two. We made quick hack changes to get it working again and quietly backed away.)

On the third side is the question of whether there's anything we want to do that the service isn't currently doing or whether this would just be a 'no functional changes' rewrite. Precautionary rewrites for the sake of putting our stamp on a program are perhaps the worst sort of rewrite there is, even if we dress it up as 'understanding the program'.

This is actually a general issue that sysadmins face every so often. We often inherit some random functioning system that we didn't build and don't have much clue about (ranging from software programs to actual servers that are configured who knows exactly how) but are now responsible for. Should we leave them alone as long as they work and don't cause problems, or preemptively redo them to avoid bigger problems down the road? I don't think there's a universal answer and I'm not sure there are better guidelines than just some general and obvious handwaving.

(In our case we actually had all of our agonizing preempted by local events. It turns out that we need some sort of general per-user email control panel web application, of which anti-spam settings are clearly a subset. This still leaves me with lots of issues to agonize over but now they're design and coding issues.)