Agile Languages and Developer Experience

I just finished reading Jamis Buck's Legos, Play-Doh, and Programming article where he discusses some significant differences in methodologies between languages like Ruby and Java. It got me thinking.

Jamis makes a number of points about how the Ruby way is generally more dynamic and less prone to specialized components. This has a lot to do with the points of extension in Ruby and the malleability of the language, itself. For instance, Ruby's ability to inject methods into existing classes or the convention of duck typing in standard libraries allow developers to pose as different types of objects and get away with a lot more than a language like Java. There are tons of arguments in both communities over which approach is better. I call shenanigans.

It's my hypothesis that both are great. I know that sounds like a cheap way to duck the flying artillery between the camps, but it's the truth. Hey, I wrote Perl for years so don't pretend to have invented the notion of language flexibility with me. (The previous sentence just started a million replies; let's pretend I've already read them all because I know what you're going to say.) I've used Ruby, Python, Perl, Java, C, C++, and others on medium to large sized, real projects so I think I can be objective on this one.

It's my experience that the problem isn't with either approach, really. I've met ninja-good developers on all sides. The wall I have run into, on the other hand, is that the amount of rope given to a lesser experienced or disciplined developer is almost directly proportional to the insanity they can manufacture. I don't think one can make a blanket statement on language suitability one way or the other.

In the past, I've used dynamic languages (heavily) for my own projects. No matter how right or wrong my own code is, it's mine and I get it, most of the time. I have a basis in C and tend to do a lot of mental book keeping when I code. It's a holdover from days when I didn't have things to sanity check my own work. There was a lot of rope, but I was the only one in the room so I made sure not to throw it over the rafters, wrap it around my neck, climb on a chair, and then try to figure out what I had done wrong. If I did, I had only myself to blame.

When I'm working with a team of fifty developers of varying levels of experience, discipline, knowledge of good design and testability, and interest in their craft, the game changes. You can't bank on each member of the team having the same skill set or even interest in what you're trying to get done. Or, maybe you can, simply by applying very strict guidelines. The fact of the matter is that it's not as cut and dry either side wants you to believe. You're going to have code-cowboys who are clever - and beware that word for it means smart, but with a hint of tricky and subversiveness - who are going to do things like override the built in functions to given them cool new uses never previously imagined! You're going to have recent university grads who need mentoring, even if only half of them know it. You're going to have your average, mediocre, developer for whom this is a nine to five gig funding an ever more expensive pot habit. And, if you're lucky, you'll have one or two super star, ninja coders, who turn out reliable, efficient, readable, documented, testable, well designed, code. (As an aside, if you're one of those people, have one, or know one, I'm looking for resumes.)

My point: do not optimize for a group you do not have.

Lying to yourself will only get you knee deep in your own rationalizations about why your language is, in fact, the best one on the planet, and how the other guys just don't get it. The worst part is you'll still be right every single time.