Writing software is hard, particularly when the schedules keep programmers “nose to the grindstone”; every so often, it's important to take a breather and look around the world and discover what we can find-ironically, what we find can often help us write software better.

In an issue devoted to emerging technologies, it seems only appropriate to discuss the issue of warnings. And failures. And adoption. And success.

In the May/June 2012 edition of CODE Magazine, Neal Ford wrote about the “danger” of dynamic languages, and in it, he quoted me from my yearly technical predictions blog entry; back in 2006 I wrote:

Scripting languages will hit their peak interest period in 2006; Ruby conversions will be at its apogee, and it's likely that somewhere in the latter half of 2006 we'll hear about the first major Ruby project failure, most likely from a large consulting firm that tries to duplicate the success of Ruby's evangelists (Dave Thomas, David Geary, and the other Rubyists I know of from the NFJS tour) by throwing Ruby at a project without really understanding it. In other words, same story, different technology, same result. By 2007 the Ruby backlash will have begun.

Neal wrote after that:

Boy, did I get email. Not angry at me, but angry at Neal for engaging in “douchebaggery” for holding me up to some kind of perceived ridicule, and that he needed to be “geekslapped.”

First of all, let's be very, very clear: Neal is a friend, a very close friend to be precise. Like many geeks who spend way too much time together, Neal and I have perfected the art of taking the “dude, you're just wrong, get over it” potshot at one another, and given that we're both speakers in the Java community, we've done a lot of it in public. I won't speak for Neal, but I know that I learn a lot from our arguments, be they public or private. Neal is an extraordinarily smart guy, and he has been known even to agree with me on occasion.

Second of all, let's also be very, very clear: I was wrong in that prediction, I think. Or, perhaps more accurately, if there was a backlash, it was a pretty mild one compared to the backlash that followed the EJB/J2EE hype wave (which gave birth to Spring and the “lightweight container” movement, right at the same time aspect-oriented programming came to crest) or the WS-* hype wave (which in turn gave birth to the “let's just do REST”, which usually means “let's just blast JSON down HTTP and call it REST”).

But above and beyond the “who's right/who's wrong” game, there's a deeper issue here that Neal addresses, and that's the “defense” of dynamic languages. In his article, Neal goes on to describe all the reasons why dynamic languages - and in this he includes both Ruby and JavaScript - aren't nearly as dangerous as they seem to a non-trivial percentage of the programming public.

Isn't it interesting that a language needs a “defense”?

Dynamic and… Dynamic?

When Ruby and Ruby-on-Rails first came into the developer limelight, the proponents of that stack offered all kinds of reasons why RoR was “better” than everything else around it (which, remember, at the time consisted of J2EE and classic Web Forms, neither of which commands much respect today). Some developers took umbrage with this position, and immediately argued why Ruby was “broken”: “It can't scale; it can't be used for large projects; it can't be as secure; it can't; it can't; it can't….”

And with that kind of dialogue, how much constructive analysis could reasonably be done? Would a Rubyist willingly admit to a flaw in the RoR approach to writing software when a Javaphile and a .NETter are just salivating in the wings, waiting for that first failure to prove “once and for all” that Ruby was doomed?

Why is it that when a new language or platform or technology comes out, we have to immediately cast it into a battle? It's almost as if “Movie Voice Guy” is standing somewhere off-stage, saying, “In a world… where developers found themselves wrapped in the chains of a tyrannical type system… one man… had a vision, where objects could change their methods… and by doing so… he changed… everything.”

Neal's own defense of dynamic languages doesn't stray too far from this model, either. When he says:

In fact, the most popular language in the world, JavaScript, has some of the most unforgiving aspects of any type system. I know that its popularity is accidental and not based on technical merit; my point is that even the most hostile of languages can be tamed when used properly.

...it almost sounds as if Neal, a firmly-converted Rubyist, doesn't want to stand too close to those JavaScript guys and their clearly-inferior language, lest the two languages be painted with the same brush (and Ruby suffer a reputational slight as a result).

Adoption and Termination

My own pet theory is that part of the reason we see so much rancor at a new, emerging technology comes directly from the costs incurred when we adopt a new technology…

... and we're wrong.

It is an unfortunate fact of American corporate culture that being wrong is worse than being idle. Contrary to what we see in the startup market, where “just f'ing do it” (JFDI) is fast becoming the new hot acronym and “Minimal Viable Product” (MVP) is the new target for people trying to bootstrap a company into existence, in the corporate world it's quite the opposite. Companies seek to take the path of minimal risk - they seek “best practices,” meaning “these are the practices that everybody else does and therefore I can't be fired for choosing them.”

At the time that Ruby came along, in the middle of the last decade, J2EE and .NET were the “best practices” of the industry. Or, rather more accurately, they were the “safe practices” of the industry. Ruby-on-Rails was the wildcard bet, and to be certain, there were companies that bet on Ruby and lost. (I won't even suggest that it wasn't Ruby's fault; in fact, in some cases, it could very well have been. Ruby wasn't - and isn't - any more perfect that .NET or NodeJS was or is.) Today, Ruby and Rails are a safe bet, and NodeJS is the black sheep bet, the long shot.

And yet, how bad of a bet could they be, really? Bits don't rot - the Delphi program written ten years ago works just as well today as it did ten years ago. The concern that somehow a program written in Delphi will “break down” is a fallacy - the worst that can happen is that (a) a new enhancement needs to be written and we can't find the original programmer and tooling to make that change (which is an organizational issue, not a flaw in Delphi), or (b) the context around which the program is executing has changed, and we need to make a change to the program, taking us back to (a).

I'll grant you - programs written for DOS 3.3 that can only run on MFM hard drive hardware (and you get to collect a Scotch from me at our next conference if you ever owned an MFM drive, by the way) are going to create a fresh new definition of Hell for you over time. Trying to replace/repair the hardware for that system is nigh impossible today, and so the program will need to be rewritten. Which, if you think about it, is the worst possible case.

Considering how often we rewrite programs just to bring them “up to speed to the latest platforms,” this hardly seems like a hardship.

Get Me Some of That

Before you get all bent out of shape about how painful it is to adopt a new language or platform, bear in mind that at the end of the day, software is just 1's and 0's. It's all “soft” - we can change and refactor it repeatedly as necessary when necessary. Offering up excuses that “this isn't a standard” is weak sauce: at one point, SQL wasn't a standard, either. Nor was C++. And yet, those both turned into something pretty useful over time.

On one of the hundreds of speaker panels Neal and I have done, he once said that there are two kinds of companies in the world: those that see their IT as a cost center and as a result something to be minimized, and those that see their IT as a competitive advantage, and seek to invest in it to gain that edge over their competitors. If you're part of the latter, you need to accept that you will make mistakes and bet wrong once in a while. You'll fix it, you'll learn from it, and you'll move on.

And that, my friends, needs no “defense.”