I can't even remotely explain how important I feel the "hit by a bus and now we don't have any who knows [x]" behavior in companies is (or rather, the lack of said behavior). I think it's just a common behavior when you have a single person work from start to finish on a given section of a software application: you have the guy who wrote the interface, the girl who wrote the server application, the guy who built the installer. Ask one of them to take over for someone else during a vacation period, and you'll likely get a blank stare and a "it's not my code so I'm not comfortable working on it", or perhaps the work will get done but get done incorrectly, thus requiring the originator of the code to re-implement it correctly.
I've experienced this at every job I've been at. I'm the ALE (Application Level Events) "master" in our product. Aside from Daniel, I'm the only engineer who thoroughly knows the specification. Aside from some coworkers' spelunking through my code, I'm the only one who really knows the server-side code. There are two coworkers who could pick it up really easily though, so the ALE service will be maintainable if I get hit by a bus.
Our security service, on the other hand, was written primarily by one guy (server-side all the way to the UI) and is a bit of a black box to everyone else (and that's how he designed the APIs, so it's expected). I've worked a bit in the security service, but definitely wouldn't feel comfortable taking it over completely without a pretty big learning curve.
That said, I think at GlobeRanger we have very good cross-pollination of our code, especially the server-side (which is arguably the most important).
One area I don't think we have historically had cross-pollination has been in the realm of building our installers. We use InstallShield (of course) and we have a single InstallShield expert. That expert has kick-started every project's installer at least, though typically he has been responsible for the entire installer from start to finish. We've had one other guy build installers, I used to build the device adapter installers (that's been transferred to one of the device adapter developers), and on our most recent iMotion version (the 5.1 bugfix/2.0 compatibility patch, which has ~40 reversioned assemblies and ~25 reversioned merge modules) I've taken over installer duty. Aside from the nuances of InstallShield and Windows Installer (how to properly format merge modules for patches, etc), I think we now have four people who could keep that one job function agile. If installer builder #1 and #2 are busy with other duties, we have a third or fourth who could take over.
Like I said, I can't even begin to express how important I feel this is. In all cases, if I were to leave for the day or leave for vacation or get hit by the bus, it is incredibly important that I leave my work in a state that could get picked up by someone else. Maybe I'll have an emergency flight to a customer for support tomorrow but we still need to release another build of iMotion.
I've worked at a place or two where I was the only one who knew half of the systems (small teams of 4-6 people in an IT department of a business shop) and others were the same. While many people take the job security stance, I think that's detrimental not only to yourself but to the business you work. First off, if a business is going to downsize, no matter how much you're the only one who knows a system, you're going to get canned (the solution, obviously, is to become incredibly skilled so that it would be a detriment to lose your expertise rather than try to stay in your mediocrity but keep your code hidden). Second, if you're the only one who knows a system, who are they going to turn to when they need some random features implemented? I don't know about everyone else, but if I had the choice between "some random boring generic feature in the system that I wrote" and the "cool new product", I'd lean towards the latter. I'd want to make sure that I have the capacity to let someone else take over my work so I can move on.
Though I think my attitude may differ from many others.
Anyway, this all started when I got to thinking about how at GlobeRanger we implemented a pretty strict automated build system quite a while ago. We built some internal development tools over a couple weeks, we invested in a build tool (instead of going with NAnt or other free ones), and build some reusable scripts to make building new scripts easier (for instance, we create a manifest of projects applicable to any given release vehicle and a build step will automatically figure out what to get, where to get it and automatically build it all through visual studio; a single parameterized step that gets fed a manifest and builds all code associated with it). My recent experience with building the installer for this latest patch release of iMotion has been amazing. I reversion a merge module (or 25), the other developers handle assigning the projects to the build, and then I click a single button to start a build of the product. We can have it scheduled for nightly or continuous building, but it doesn't do us much good on these minor releases.
Our original procedure involved one guy building everything on his box. All modules, all code, everything. That got tedious so he built a one-off to build all the code and installers. Unfortunately it was incredibly cryptic and suffered from it's-how-he-works-so-you-can't-understand-it-easily (e.g., he works in a certain pattern that is drastically different to yours, so understanding the system is more of a pain) and now this build system is a hit-by-a-bus problem. Eventually that got moved to a build box which helped on standardization and cleanliness of builds, but nonetheless it was problematic. Then we got a build tool and invested in internal development tools and made sure to implement 1-button click builds and we now have the capability to allow just about anyone to work with our builds. All we need now is a way to automatically have our merge modules build themselves!
The reason I was thinking about this is I'm leaving for my honeymoon in a couple days and I'll be gone two weeks. I'm incredibly confident that this project won't stagnate and any one of the developers will be able to handle building the product in my absence. I won't receive any "sorry to call you on your honeymoon, but, um, we can't figure out how to build the product". I won't come back to a huge list of tasks because somebody else couldn't figure out how to take care of my stuff while I was gone. Perhaps I just don't want to feel important enough and require people to call me if they want to touch "my stuff". Or perhaps I just like to have some peace of mind while I'm away.