Objective:This came up in the car yesterday as I was driving back to the office with one of our summer interns after a visit to our datacenter. Apparently he'd never had to deal with someone-elses code before, which made this summer a rather eye-opening experience for him. He came into the middle of a product that many people had contributed to, has over a year's complexity built into it, and is very much not like the kind of thing you work on in CSci courses. An exercise like the one I outlined above would be rather useful for aspiring Software Engineers, since they'll be working on other people's broken crap for a good part of their careers.
You have been hired by a company after a developer was fired for cause. Another developer looked at his stuff and found it seriously lacking. He failed to live up to his obligations and was let go. However, the project he was working on still needs to be completed. There isn't time to build it all afresh, so you have to make his non-working code work. You have one week.
It's also a lot of what Sysadmins run into when starting a new job. The tendency to haaaaate your predecessor is strong because they did things so very differently than you do it. Also, a significant part of our troubleshooting time is spent diagnosing problems in other people's code, both operating-systems and applications, so this is a well used skill for the likes of us. Even closed-source black-box binary blobs.
Definitely a skill that can be taught, and a good idea too. Once the concept of 'maintainability' has dawned, it definitely does change how you build your programs. Or automation scripts.
I had such a course during my Computing (Not Comp Sci, this counted as an engineering degree) course, in the form of a "Software maintenance" module. This consisted of how to work on other people's code, refactoring, creating glue and shims to avoid changing existing code, and reverse-engineering of requirements to determine how/when to replace broken or old code. This also covered having the source or not, as it's quite possible that the thing you're working on/fixing/extending isn't even on the same machine or in the same physical location.
This was possibly the single most useful (and difficult!) course during my degree; certainly the most directly applicable.
This was an optional module unless you were doing the 4-year Software Engineering Masters course, unfortunately. One course on maintenance in 4 years is a start though :)