|Perl: the Markov chain saw|
Except when you have to maintain it.
Blackboxes, such as people in certain roles and code, are evil. Sure, roles can become quite valuable, just like some projects, and require some study to understand, but it's hurtful in the end.
Should one maintain this code, without refactoring anything, and making things "better" (to maintain or in scalability), you'll add months, maybe years of your view of how things should be on top of the prior person's. He may not be a bad coder, but if it doesn't do things "right", i.e. using functions/methods to encapsulate shared logic, CPAN where things are done "right", then you increase the size of the project and wind up with a big ball of mud.
The same could be said of roles in a company. If someone holds too much information and doesn't share, they become a blackbox and in turn, become dangerous.
If he does convince them to redo it, he has to be sure to find out how much of the project the code represents, and the code itself, is. Piecemeal vs in one big shot. Anytime a choice exists, it would have to be weighed out in conjunction or in place of other options.
It's all systems analysis and design.
Bart: God, Schmod. I want my monkey-man.