With apologies to Mark Twain

There are always timesinks at a job: the things that suck up all your spare time, that interrupt what you're doing and force you on to something else. They're urgent, or they're complicated, or they're obscure and you only ever touch them every six months. If you're really unlucky, they're all three. They drain the life from you; a good day turns shitty, and an already-shitty day becomes nigh-unbearable.

The website is one such timesink at my current job. It's a veritable Grand Canyon of different technologies, databases, and code. You can examine it and, like a geologist, date particular pages or code with great accuracy, judging by clues like composition, surroundings, indentation patterns ("Oooh, K&R crossed with…crack?"), and previous experience. When an Urgent Request for Web Changes comes in (and they're all urgent), figuring out how to do it means figuring out how that particular page was generated in the first place: static? dynamic? CMS? And then you have to figure how you can meddle with it: logging into Mambo, the CMS of the damned? If it's static: does the URL map nicely to the filesystem, or is there a hidden Apache Alias directive somewhere? Do you have permissions to open the file, or will it take sudo to chown it, or another nagging email to a coworker to please check their changes into RCS? And if, God help you, it's dynamic…but no; that mess of spaghetti should stay down. There's no sense bringing it up again simply for prurient purposes.

Sunray terminals are another timesink. When they work they work very well. I like the energy-saving aspects of it — both electrical and my own; one machine to manage is always better than 40. But when they don't work, it's a pain. Has a session become wedged? Is it GNOME's fault? Has Adobe Acrobat decided to eat up all the CPU again? If so, is that worse than the security holes that remain unfixed in the later version? Why is Solaris 10 randomly not sending RST packets when it receives a SYN on a port it's not listening on? (If anyone has any ideas, please let me know.) Has a cheap switch, installed because no one believed that an office meant for one might someday hold four, gone off its meds again?

These things make me throw up my hands and and curse my fortune. I have no one unfortunate enough to be my subordinate, so it's up to me to hack and slash through the possibilities until it's finished, or at least put off for another day.

But LDAP is worse.

When it works it works very, very well. Failover works, replication works, and an account created here zips there without a moment's thought. But when it fails, it's urgent and complicated and obscure all at once, and sometimes in degrees polynomial.

At last count we have four different master-master replicas, running three or possibly four different versions of Sun's Directory Server (under six different product names, no less). There are replication agreements spanning versions that aren't even supposed to tolerate each other's existence, using two different encryption protocols and NetBEUI. Two completely different "helpful" management tools vie for our attention, lacking only flash plugins to trigger seizures. Only one server can be poked or prodded with a command line tool. Diagnostics are by turns nonexistent or endearingly fickle.

To be fair, the vendor documentation is vast and makes fine kindling, though its promise to fully document error codes like error 457758854b: BER error 45775885b4 is best regarded as a bitter joke by a jaded software engineer who died alone, unloved and without stock options. (Our own documentation is marginally better: no carbon is released when it is destroyed.) Thus, keeping track of ACLs (say), and exactly which unholy wrath you will invite upon your head should you make a mistake when granting or revoking privileges to read a particular entry, means digging through half-remembered conversations, drunken Google searches, year-old notebooks and a quiet, solitary introspection normally reserved for contemplating your own impending doom.

On top of everything else, LDAP encompasses everything, or nearly so. Email routing, website privileges, database access, even TCP checksum computation: all are kept in, or depend on, or just like to hold hands with, LDAP. It's enough to make me wistful for the good old days of NIS.

In a few minutes I am going to go back to work and try to figure out why a new account has stopped, in mid-replication, halfway between $UNIVERSITY and $OTHER_UNIVERSITY. It will take me the rest of the afternoon. I will use words that my own son does not know I know. And I will come out of it shrunken, withered, beaten down and humble.