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.