Rails as a disruptive technology

Bruce Tate's discovery of Rails and his comments about where it could (or should) be applied got me thinking of Clayton Christensen again. I've been reading The Innovator's Solution (and the Dilemma too, actually). In Christensen's model for describing disruptive technologies, Tate's description fits in nicely with the notion of over-served customers:

I’m not going to pretend that anyone would ever use Rails for everything. But think of the number of applications that you build that do nothing but put a big web front end on top of a persistent model. That’s a huge part of what we do. If Ruby and Rails can make you that much more productive, and if it solves the problem, why wouldn’t you?

The industry is being massively over-served by J2EE/.NET in the majority of projects. The backlash against EJBs and other Titanic-type technologies demonstrates this well. And I see a hope in the increased collective awareness that maybe not all projects need the tools targeted at the very most complex ones. And not only don't need, but are damaged by.

In this frame of thought, Rails is able to deliver incredible improvements for the majority of projects that are currently being over-served by J2EE/.NET by sacrificing a whole herd of golden calves. The sacrifices are condemned by the high priest exactly because of their status as high priests, which means they work on the most complex projects and hence cast all decisions on technology in that context. Would this work for the 5% most difficult projects? If not, then it "doesn't scale".

This, according to Clayton's theory, invites the incumbents and their high priests to flea higher up in the market when attacked at "the low end". They seek refuge by attempting to deal with even more complex cases, which in turn makes their tools even more complex.

At the same time, Rails as a disruptive technology undergoes rapid improvement that expands the number of projects for which its a good fit all the time. What may have started as only suitable for simple projects become suitable for medium projects (top of the bell) and in time becomes suitable for the complex and even very complex projects.

As this process unfolds, it's natural that both a fair share of cognitive dissonance will be developed by the incumbents and their high priests and that a lot of companies following them will be caught in the competency trap. High rents are being extracted from the accumulated knowledge and technology held by big corporations and the companies and consultants around them. Attempts to uproot will not be taken kindly.

I think many programmers are also interested in complex things in and of themselves for the "intellectual challenge", and thus embrace over-architected and complex solutions for the wrong reason, in a business sense - that is, getting the job done efficiently and quickly. I'd guess this is another factor in the "high priests" clinging to those technologies.

It seems that it's often those down in the trenches, doing the everyday hard work are frequently the quickest or most willing to embrace simpler and more productive solutions. Not that they don't enjoy a good challenge, but when it turns into endless drudgery and long hours at the workplace, priorities tend to shift... versus those spending days debating architecture on whiteboards and meeting with the marketing team for new products, for whom the day-to-day tasks of building things sometimes seems to recede in importance.

It was a nice surprise the comment by Bruce Tate. He is the one who I would look for advice by reading his books and comments in the Java Land, because he is one of the most pragmatic around there. It coincided with a comment by me where I cited his name as a good one to look for Java "advices", and then, today I saw his Ruby on Rails comment, which just proves my point.
Great day today.

... and as Rails works for more and more complex problems it too becomes more complex. Soon someone says "you know, if we forget all that complex stuff Rails addresses we can do this really simple thing" and the whole thing starts again, but *further* ahead. When I look at cycles like this it feels a bit like a hysteresis. In that case the "backward" leg is a new technology driven by re-applying the 80/20 rule to the problem domain. In this way we make forward progress, each time the 80/2o rule is applied we bite off another chunk of complexity and make it simple.

The cycles are natural. They're called progress. I hope that some day Rails will been seen as too complex if its unable to adapt. That would mean we've made another round of great progress.

I just read this article on Server-Side. It's probably not completely true but it's basic message is clear: the big players must deal with unnecessary complexity, too. I really hope that as Ruby on Rails in gaining more momentum that a big company like IBM will consider it as an option for future web development. Come on, IBM, Ruby is so much better than PHP.

As a J2EE developer, I've definately seen the trend towards simplification over the past few years. Part of the problem is definately Sun, and their tendency to create standards before having a good implementation. People have finally begun to realize that EJB's (entity beans anyway) are a solution without a real problem. Projects like Hibernate and Spring are steps in the right direction. More can always be done though.

I think people may underestimate the importance of making it easy to get started with a new , which Rails seems to embrace. Anyway, just for comparision purposes, I've been doing some comparative analysis of Rails, specifically vs Hibernate over at my blog, here

While IBM realise there are other options aside from PHP , they have to deal with a competitive market day by day. For future web development maybe but it all depends when they want that future to happen

i am an idiot and i am lead by richard simmons