Which is precisely why he's leaving. Poor Rupert has been trying to spend more time with the rest of the .NET team doing cool stuff, but he keeps getting dragged off to fix the old SCLABE* system.
Any time a tweak is required, Rupert's manager gets Rupert to do it, because he's been here the longest, knows it the most, and can fix it the quickest. And he knows exactly why an extra column is added on alternate weekends - a previous customer was having problems with their invoicing, so this was introduced to get round it.
But now Rupert's off, all his manager can think to do is get him to document what he knows about SCLABE. The thing is, Rupert's motivation percentage is equal to the number of days left at the company; today there are 17 days left, so he is 17% motivated. So Rupert adds a table of contents to the document, changes the headers and footers, tweaks "Heading 2" so it has 6pt spacing before and 12pt afterwards. He writes about the objectives of the system, describes the main areas of the system as an overview, and spends the rest of the day trying to get Visio to draw something resembling a diagram of the system.
In other words, he's wasting everyone's time.
To be fair, he's asked what he needs to write, and the answer was "enough for someone else to take over from you". Well, to take over, they need to know what the thing does, right? But that doesn't really help the next guy (who had better not be me) when the next tweak is required. There isn't any documentation that will help. There can't possibly be. Why? Because it isn't Rupert's knowledge that needs to be passed on, it's his
experience. And that can't be passed on in a document. I can read a document telling me how to do a
backside footplant wallride, but that doesn't mean I understand it, let alone have any success with it.
So what to do? For Rupert's boss, not a lot, except learn for next time. Rupert's experience needs to be passed on, which can only be achieved by showing someone. Although I've never been a manager, if I was stuck managing SCLABE, I would find a volunteer or two (willing or otherwise) to learn from Rupert. When a tweak is required, the volunteer, let's call her Ingrid, would sit at the keyboard, with Rupert next to her. Rupert would tell her how to navigate through the code, what to look for, how to implement the change, how to test it, where to deploy it to, and everything else, without actually doing it himself. Rupert would answer questions, and sometimes withhold information to make sure Ingrid thought about what she was doing. She would either work it out, or have to ask the right questions.
In this way, Ingrid would actually experience the system, and start to understand it. After a few of these sessions, she may be able to fix some things by herself. This would free up Rupert to get on with the cool AJAX stuff. If Rupert spent time with others in the team, then it would seem fair, and people could take turns. If Rupert left, then SCLABE fixes wouldn't be a major trauma, as someone else could do it. Rupert would be less likely to leave anyway, as he's now a confident, successful mentor, and even has time to write some Ruby on skis.
* SCLABE is a fictional legacy system written in COBOL on an AS/400. Rupert is a fictional developer, whose resemblance to anyone you know is the whole point of this exercise.
