Better than Better

by Tina Darmohray
<tmd@usenix.org>

Tina Darmohray, editor of SAGE News & Features, is a consultant in the area of Internet firewalls and network connections and frequently gives tutorials on those subjects. She was a founding member of SAGE.

Have you ever felt a little sick as you looked at code that implements some critical aspect of your business—because it looks like noodle soup, and you were hoping for something sleek and clean, like the stainless-steel kitchen it was created in, instead? I've seen my share of these homegrown tools that are ancient creations with decades of feature-creep and no remaining engineers to tell the story of why it was originally created this way or that. Even the comments are a sad state of affairs, although entertaining, in their own way; the obviously earlier ones sound authoritative and confident, whereas the more recent ones have a tone of submission: "added to work around section B."

The original code, which has had years to ferment, probably implemented some fabulously necessary feature, maybe even in some straightforward way. But, over the years, it's been built on and added to by many other talented and clever individuals, all adding a feature here and a workaround there. Over time, these creations become huge monolithic examples of how not to design modular, nimble, easily supported code. In some cases, enough time has passed that some features cease to work, and still others continue to, each without anyone still on board who can remember the purpose of either.

I don't believe anyone sets out to create these beasts that ultimately take on lives of their own, but, sadly, they're in no danger of extinction. Many sites suffer from one form or another of them. One day they're a good idea, the next they're behemoths causing more trouble that they're worth. If only there was an easy answer, but as awful as it is living with 'em, many sites fear they can't live without them, either. It's sometimes hard to make the big decision to take on that long-overdue ground-up redesign.

The two most egregious examples I have of these feature-full monstrosities both revolve around mail configuration. (Just for the record, I think this speaks to the fact that I get called for mail messes, more than it does that mail is always a mess!) It's not hard to figure out why sites are reluctant to do a ground-up redesign; I always tell folks that mail administrators don't need pagers, since users hunt you down and find you within moments of mail-system failures.

It feels like it's easier just to patch the existing system than to tackle the fundamental problem. So it ultimately worsens. In one case, I saw a sendmail.cf file that was over 23 pages long. (Contrast that with a more average length of nine or so.) This file was truly spectacular. The blade salesman would accurately describe it as "it slices, it dices, it makes julienne fries." It did everything, and at the same time, it was unwieldy and unnecessarily complicated.

When I first saw it, I immediately (and maybe somewhat naively) suggested just using the standard sendmail.cf files currently available. Sadly, this site suffered from the NIH syndrome, and it became clear I would spend my time arguing with them rather than fixing things, so I added another feature, since so many others had, and went on my way. I just heard recently that they finally took my now three-year-old advice and switched over to a standard file. Their stuff works just as well, and it's a lot easier to support, now that it's more in line with what most of the rest of the world does. True, they no longer have a souped-up .cf file that was a coding marvel, but they still have something that is lean and mean and worthy of admiration in its own right.

The other mail scenario I remember wasn't the .cf file, but was code modification to sendmail itself. The modifications were originally done because sendmail was missing some required features. Over the years, the programmers who modified the code eventually moved on, and support of the proprietary code became increasingly difficult. Ultimately, new sendmail capabilities were able to provide the site with the same or similar functionality and enable them to move to the stock sendmail. By doing so they eliminated their precarious position of relying on an unsupportable code base and enabled themselves to take advantage of some of the additional new features of the new off-the-shelf software. As with the other site, mail still flows, but there is a lot less gnashing of teeth involved to keep it that way.

I guess I'm not fancy, when it comes down to it. Or maybe I just lack vision. But I stand by using standards when you're talking about the backbone for your infrastructure, your services, and your servers. In the long run I think you'll run a tighter ship, with a lot less effort. Call me boring, but sometimes "standard" is just better than "better."