Nannies for Blimps!

In the old days, the compiler was your nanny, because computer resources were expensive and delicate and huge, like a giant hydrogen blimp. You want to fly the blimp, baby, you better be really good at flight plans.

So static-typing was one of several ways to prevent us from blowing up the blimp at runtime. (This metaphor may not work for too many more paragraphs, but I am flying with it for now anyway.) Static-typing is really a sort of BDUF (Big Design Up Front) enforced at the language level. It imposes design straitjackets that only become plain once a dynamic language has removed them from you. (Wow! You can do THAT in this language? Really? Look at how much less code that is.)

The Nanny is Not Groovy, Man

Extending designs in Java is genuinely hindered by static typing. It’s no longer a political issue, it’s just plain fact. And I don’t just mean because it takes 400 characters to print “Hello World.” No, I mean the kinds of shenanigans imposed on every type you inherit or use or create. Think: generics, and how long it took for Java to get them, and what a pain in the arse they are. The Nanny really is everywhere in Java, to my mind.

Bruce Tate, Stuart Halloway, Justin Gehtland, and others have made passionate, convincing argument that (for example) convention-based Rails programming as a means of getting an enterprise web app “off the ground” (so to speak) may be faster than the lightest-weight J2EE frameworks by a factor of 10. Maybe more than one factor of 10. Sheesh, that Nanny is EXPENSIVE! How would your stakeholders like it if you could produce 10 times as many web applications to solve enterprise problems than your teams can today?

The catch, of course, is Ruby and its still relative dirth of supporting libraries, frameworks, and similar open-source support. And Ruby syntax looks wonky to us old Algol-based fuddy-duddies. This is why I am personally so attracted to Groovy and Grails. (Introduced to me by Andrew Glover of Stelligent and Chris Judd at CodeMash in Ohio last month.) All the convention-based goodness, plus leverage of my Spring and Hibernate experience, and I can still use the Java stuff that the mean Nanny pounded into my head over the years. (Just the good stuff. She’s not a completely mean, insane, dictator nanny, I can now see in retrospect.)

Look Nanny, No Unit Tests! (Uh Oh.)

So off we go to a dynamic language, full of our static-typing outrage. The catch, of course, is this: because you can send a “divideYourselfByZero” message or any odd message you like to the integer 42 in languages like Smalltalk, you can get runtime errors of the sort that would curl a Java programmer’s hair.

Does it suddenly make a bit of sense why the first member of the xUnit family was, in fact sUnit? My question for the Smalltalk crew is this: before you had sUnit, how the heck did any of you keep your jobs? The production deployment problems must have been Hindenburg-spectacular. (I’m partly kidding. Actually, it turns out, the really good Smalltalkers had other tricks up their sleeves to avoid runtime disaster.)

So the bottom line is this: with dynamic languages, You Have No Choice but to develop exhaustive, requisite suites of true unit-level isolation tests. Oh, plus end-to-end tests, and several other automated test varieties. This is the equivalent of venting out all the Hydrogen and replacing it with … Helium! Yay! Doesn’t explode, a bit more expensive, for sure, and not quite as “lifty,” but way safer, and you can still fly.

With dynamic languages, you have the authority and responsibility to be an adult, not a child. No more Nanny, so no more stepping out into the street before you look both ways.

Note to Recruiters: Hire the Guys Who Know Dynamic Languages, No Matter What They Charge

Power Programmers, Alpha Geeks, the ones who some now claim in public (reasonably, I believe) can outproduce “vocational programmers” by a factor of 10 or more (there is that same math, hmm)? It turns out that one of the primary indicators of one of those guys or gals is that they just cannot keep their hands off of lots of different languages, and operating systems, and computers, and you name it. Some of them actually play banjo! They are really good at comparing entire language systems and development systems to one another. They really like dynamic languages, because they are so much faster and cleaner and better. And they really, really like unit tests, because suites of them save their behinds so frequently.

Oh, BTW, you know what true alpha geeks are all on about these days? A good old idea come full circle: functional programming. Oh, and also, BDD. Whee, here we go!

Alpha Geek example: my alpha geek pal Dimitri says “dynamic languages are so much more expressive it’s not even funny.” He says that when he noticed that Ruby does not require generics, “I almost started crying.” He says “I think the whole thing can be summarized as: static typing breeds incidental complexity”. Great quote. And he correctly points out that in the emerging world of Domain-Specific Languages (DSLs), dynamic languages are absolutely vital.

So save the really big programmer salaries for the ones who (A) know unit testing backward and forward, including TDD, (B) know multiple languages, and program avocationally and recreationally, and (C) can spout endlessly about the benefits of once-seeming exotica like dynamic languages and functional programming. That, at least, would be my agile alpha geek definition. There are other kinds of alpha geeks, certainly. In my big enterprise app world, I need the agile ones.

Hire guys like Dimitri. Make sure your team has a ratio of at least 1 alpha geek to every 3 or 4 non alpha geeks. And be the kind of boss and organization that alpha geeks love to work for and with (yet another blog topic, for another time).

And be the kind of boss who enables non-alpha geeks to find their way to alpha, if they want it. Again, another blog for another time.