Inchoate Curmudgeon

Zed Shaw is ranting about Rails. The effects are palpable. People are talking about the post. I’ve seen no less than a dozen tweets on Twitter in the last hour or so, and it has been by far the vast majority of the tweets about Rails.

The post is clearly consistent with a theme of healthy and vigorous commentary that Zed generates about the ethics and behavior of folks in our world, the industry and on the Internet. His position can be summed up as follows: don’t do anything on the Internet you wouldn’t do in person.

Zed practices what he preaches: his real-life persona is the same as his Internet persona. It’s unapologetically in your face, wall-to-wall polemics.

Zed’s style definitely gets more attention than any feeble musings pretty much anyone might write on this topic. This is bad, since it further reinforces and supports his thesis that our world is filled with people who can’t be bothered to think critically about much of anything, at least without something like his fiery delivery to get your attention.

Ironically, he lambasts even Dave Thomas in his post. Dave delivered an emotional address in the last Rails conference in Portland that asserted the Rails community is what is important about the Rails phenomena, not the technology. But hate and love are both part of life, and whatever it takes to get people thinking and talking about this subject may be worth the risk of collateral damage. Zed proves it takes short sentences with one syllable words, generously sprinkled with expletives.

I love that people are talking about Zed’s post, and pray that people really read it. I hate that it takes this kind of delivery to get people to talk about the subject, and pray readers do more than just say “Wow, he’s mad” or “Wow, Zed’s leaving Rails.” That would truly make his exit pointless.

I stumbled across more detail from Rich Manalang regarding the Oracle Mix deployment on JRuby and the Oracle Application Server. I orginally wrote a post about this after meeting Rich and Jake at Oracle World last week.

Its more than a little interesting, but not surprising or atypical, that finding production hardware consumed so much of the team’s attention.

How many enterprises can deploy any useful, inovative, inexpensive, rapidly developed application in less than several months, much less in weeks? What happens in a year or so when there are hundreds of these completed applications in backlog, waiting for a home, rather than one or two?

The Ruby on Rails phenomenon is part of the modern equivalent of the IBM PC that killed the mainframe glass-house operation. Enterprise IT organizations ignore this fact at their peril. An IT operation that can’t deploy new applications, without procurement cycles, in minutes rather than months is doomed far sooner than we may think.

I was on a staff call this morning where the subject of red-shift came up. Its a hot topic with the Sun Executive, promoted to help balance our focus between bread-and-butter data center solutions and supporting atypical, non-traditional, hyper-growth markets requiring massively scaled, extreme-availability solutions.

Of course, it’s easy to pick a heated discussion in relation to what is and what isn’t red-shift, but at its core, it means acceleration, speed and massive scale. Things are fast and getting faster, big and getting bigger, and more of this trend is happening disproportionately in non-traditional markets and start-ups over traditional, enterprise operations.

For Sun, red-shift impacts and opportunities are a key engineering focus. Most apparently, this revolves around transforming the data center from a spaghetti-like, hodge-podge mass of mind-crushingly complex interactions into a massively-scaled, computing powerhouse; transforming a pile of machines into a far more cohesive and efficient whole.

I also read an blog post bemoaning the tendency for technical staff in organizations to hoard arcane information and knowledge for gain.

It might not be readily apparent, but these things are related.

The ability for the market to absorb and effectively leverage the decreasing cost and increasing power of computing is related the ability of developers and architects to rapidly develop, deploy and manage solutions. This is the true story of the power of Ruby on Rails, and this is not a technological story.

Rails developers of all kinds are able to develop and deploy applications at astonishing speed. Although the technology doesn’t get in the way, it’s not the whole story.

If you were to go onto the Ruby on Rails IRC, at irc.freenode.net, #rubyonrails, you will find at any time of the day or night, no less than 500 developers, conversing. These developers are asking and answering Rails questions, at amazing speed and in astonishing numbers, in real time. My mailbox is filled daily with digests of Rails mailing list activity. This is a very active, friendly and helpful community.

This is the real key to the power of Rails. Rails is a Web 2.0 technology, if there is such a thing, eating its own dog food in a big way.

There is no particular advantage given a large organization versus a small one in leveraging this kind of ready on-line technical capability. Small organizations and individuals who may have been developing slowly and alone using other frameworks are now powerfully enabled, and I’d argue more enabled, to develop useful, effective solutions than their enterprise brethren. Locality to a cult of Wizards is not required to become an effective Rails developer.

In fact, in the information marketplace cultivated by the Ruby Rails community, enterprises are extraordinarily disadvantaged on many levels. For example, when the small development organization, in that small company, is ready to deploy, the answer is increasingly solutions like Joyent, Engine Yard and many others. Who needs a data center?

The classic barriers to anyone, large or small, rapidly developing and deploying massively scaled solutions are evaporating. Can a typical enterprise developer ditch his IT organization to deploy a new application in 5 minutes instead of 5 months? Leaving aside the 10-20% of solutions that no-way fit an out-servicing model, isn’t out-servicing a viable 80% solution?

So, at all levels, traditional approaches to building and managing technology are being disadvantaged, and will be swept away, by the think small, move fast, get things done alternatives. This trend will be able to consume all the red-shifted engineering Sun can generate. Does anyone remember when the PC killed the mainframe? This is a classic, inside-out, David versus Goliath story unfolding right now. Don’t blink.

I’m at the RailConf in Portland, hoping to learn a lot about Rails. I’m off to a tutorial on JRuby! I’m going to a BOF for Flexible Rails hosted by the author Peter Armstrong.