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.
