You hear that, Mr Andersen?

Cats, Lists, Final Decrees, Tar-babies

An odd varient on StuffOnMyCat.com -- CatsInSinks.com.

And in a return of an old favourite -- Timothy McSweeny's lists include Totalitarian Institutions That Would Have Been More Fitting for George Orwell's 1984, Considering How That Year Turned Out (including "The Ministry of Fools, and the Pity With Which Mr. T Regards Them"), and Klingon
Fairy Tales (starting with "Goldilocks Dies With Honor at the Hands of the Three Bears").

***

I remembered playing a board game five or more years ago with the inimitable Mr At-Large; I knew that he'd downloaded it off the web, but I couldn't remember what it was called. So I summoned up my Google-fu and what I remembered of the gameplay, and after a few false starts found Final Decrees. Basically, you play high officials in charge of one of five bureacratic departments of a galactic empire on the verge of collapse, and the aim of the game is to be the official with the least personal blame when the game ends. With departmental powers like the Secret Service's "Investigate Head of Department" (which changes all departmental blame into the personal blame of the head of that department) and action cards like "I Have Something To Confess" (which lets you take blame, but give twice that amount of blame to someone else), it's pretty nifty. And also, free. :)

I think that it might have been the Yes, Minister discussions that triggered this memory.

***

One thing that people who aren't programmers might not know is -- code is sticky. Some bits of code are less sticky than others, but some are like the proverbial tar baby. I think the main reason for the "you touched it last, you fix it now" attitude is that code is complicated -- even if you've provided excellent documentation and your code is clean, beautiful and intuitive, programs are complicated things, and it's non-trivial to build up a mental map of how it works, so it's almost always faster to ask the person who's already gotten into the guts of that program to go back to it, rather than paying the start-up costs of someone new learning it.

However -- while there are seductive and powerful reasons to go down this path, once you start, forever will it dominate your destiny. For starters, it results in you having "indispensible guy" problems, where there's only one person who knows how a key tool works. And you find people are really reluctant to touch things that are either difficult, or have difficult users attached to them, because that may doom them to being the person responsible for that tool for the rest of time. And it eventually bites you in the bum when the go-to-guy is unavailable, and no-one else knows anything about the system, and all the documentation is in go-to-guy's head.

As you may have gathered from the Dark Side allusion, I'm not in favour of this approach. Especially when it results in me having to do extra work. ;) (rassen-frassen-"all coders are busy"-schassen-frassen.) It's weird to think that will have been a DBA for a year soon, and I still haven't completely escaped my former department. Not that I'm really that grumpy about it -- I mean, I enjoy programming -- but I'm aware that time is running out, and the things that need to be ready in time for the next project keep getting pushed down the list. Part of this is my fault, since I need to put time aside to do the long-term projects; but I don't actually get very much uninterrupted time during work hours. Ah well, you do the best you can, etc. etc.