|No such thing as a small change|
Lately I've been busy correcting the work of lots of unsupervised programmers, and I've come to think something different about this whole debate. It's not the tool that matters, but the people choosing the tools. Their decisions are not rational or based on technical merit, and we can't solve this problem with reason or merit. There are good reasons to choose Java for some things, just like there are good reasons to choose Perl for other things, or even Python or Ruby or something else.
The problem doesn't have much to do with the language. It's a failure in management. Now, I know the you (Jim) use Perl in your department, but that you also have regular training for everyone, comprehensive code reviews, and that you follow the technology. Not too many places I run into seem to do that, even at the technical worker level.
Thinking about that, and after listening to an interview with AT&T's Ed Amoroso, and probably after reading a bit too much Joel Spolsky, led me to think that the lack of management is the problem in these cases. Aside from the usual, puerile generalizations about pointy-haired bosses, in my fire-fighting work I've noted several things that set up the problem. (Update: I'm not generalizing about managers, just some patterns of behavior I've seen from some people in those positions. Being a manager doesn't mean you do any of these things :).
There are all sorts of reasons why any of those things might be true, and not all of them are bad or even the manager's fault:
No language is going to solve any of those problems, but I've heard many Java proponents say that they can take mediocre programmers and turn them loose without worrying about them. The problem there isn't Java, it's the lack or worry (which you should really read as "supervision"). Managers don't want to manage.
A language like Perl, however, just makes the management problems more apparent, mostly because Perl doesn't let you blame some things a Java programmers gets to blame (and sometimes with good reason).
brian d foy <email@example.com>
Subscribe to The Perl Review