From these steaming entrails, I divine the future...
I've recently been doing a lot of experimentation with Ruby on Rails. Short summary: the hype is largely deserved. It's completely bad-ass, eliminates all kinds of redundant bullshit...and I'll probably never get to use it in my current job.
There are two major barriers in the way of adopting Rails where I work. One is that we have a proprietary Java-based platform that's been in development for almost four years. Pretty much everyone in the company uses it, all of our various systems expect to work with it, and it would be difficult to throw over for something else. That's a pretty typical issue with platform migration, though, and probably isn't too surprising to anybody.
The other, and in my opinion more significant issue, is that Rails seems to work best when a given developer can build both the database and the app code. This is tough to manage in a larger company. We currently have one team that does all database development. The benefit of this is that the DB is left to the specialists, who can enforce uniform schema quality and data interoperability between different apps. The drawback is that coordinating between the app teams and the DB team is difficult, and the DB team is consistently overworked; thus, it takes a long time to get anything done.
With Rails, though, most of the work involved in setting up a straightforward web app is the data modelling. If your data modelling is slow, then you've lost a lot of the benefit of using Rails, and you can't do a lot of the cool iterative stuff that you can do with it, because changes to schema take forever.
Thus, I think the more significant barrier to Rails adoption in large companies is a structural one. Anyone who's worked in a corporation knows that, continual reorgs notwithstanding, it's damn near impossible to change the structure of power and responsibility. There are just too many vested interests, and too many people playing politics.
Anyway, I think I've given up on the dream for now. I've been thinking a lot about what this means for Rails' uptake, though. I think you'll see this division-of-labor issue block Rails from making a lot of inroads in "the enterprise." On the other hand, it will encourage a lot of adoption in small startups. Small, nimble companies will become even more nimble using it, but large, slow companies will not be able to derive much advantage from Rails.
On a broad scale, this increases the ability of small, nimble companies to compete against the juggernauts, and that's pretty cool. What happens, though, as the non-failed Rails startups continue along?
Do they just not grow? I'm no biz guy, but I assume you're never going to be able to take a company public if you don't expect to grow.
Or do they get huge and stick with Rails? Presumably then they start running into division-of-labor and data reusability issues. They get clumsy and execution suffers, and they've thus obviated a lot of the value of Rails.
Or do they get huge, switch to Java, and watch all of their founding developers quit because everything's such a pain in the ass now?
There's another possibility to consider. It's possible that the "convention over configuration" philosophy might work just fine on a grand scale. If all the teams in a company are building their models to work with Rails, then they should work with all of the other teams' apps as well. Maybe the secret is just to assign responsibility for a given model to one team. Other teams could even make changes to that model, but the owning team would have release authority...
In that case, large companies could benefit greatly from Rails, but only those companies that started with Rails when they were small. Big companies have too much existing data that doesn't fit into the nice clean Rails conventions, and aren't likely to reorganize to the point that they could devolve responsibility for data to the various app teams.
Anyway, food for thought.
There are two major barriers in the way of adopting Rails where I work. One is that we have a proprietary Java-based platform that's been in development for almost four years. Pretty much everyone in the company uses it, all of our various systems expect to work with it, and it would be difficult to throw over for something else. That's a pretty typical issue with platform migration, though, and probably isn't too surprising to anybody.
The other, and in my opinion more significant issue, is that Rails seems to work best when a given developer can build both the database and the app code. This is tough to manage in a larger company. We currently have one team that does all database development. The benefit of this is that the DB is left to the specialists, who can enforce uniform schema quality and data interoperability between different apps. The drawback is that coordinating between the app teams and the DB team is difficult, and the DB team is consistently overworked; thus, it takes a long time to get anything done.
With Rails, though, most of the work involved in setting up a straightforward web app is the data modelling. If your data modelling is slow, then you've lost a lot of the benefit of using Rails, and you can't do a lot of the cool iterative stuff that you can do with it, because changes to schema take forever.
Thus, I think the more significant barrier to Rails adoption in large companies is a structural one. Anyone who's worked in a corporation knows that, continual reorgs notwithstanding, it's damn near impossible to change the structure of power and responsibility. There are just too many vested interests, and too many people playing politics.
Anyway, I think I've given up on the dream for now. I've been thinking a lot about what this means for Rails' uptake, though. I think you'll see this division-of-labor issue block Rails from making a lot of inroads in "the enterprise." On the other hand, it will encourage a lot of adoption in small startups. Small, nimble companies will become even more nimble using it, but large, slow companies will not be able to derive much advantage from Rails.
On a broad scale, this increases the ability of small, nimble companies to compete against the juggernauts, and that's pretty cool. What happens, though, as the non-failed Rails startups continue along?
Do they just not grow? I'm no biz guy, but I assume you're never going to be able to take a company public if you don't expect to grow.
Or do they get huge and stick with Rails? Presumably then they start running into division-of-labor and data reusability issues. They get clumsy and execution suffers, and they've thus obviated a lot of the value of Rails.
Or do they get huge, switch to Java, and watch all of their founding developers quit because everything's such a pain in the ass now?
There's another possibility to consider. It's possible that the "convention over configuration" philosophy might work just fine on a grand scale. If all the teams in a company are building their models to work with Rails, then they should work with all of the other teams' apps as well. Maybe the secret is just to assign responsibility for a given model to one team. Other teams could even make changes to that model, but the owning team would have release authority...
In that case, large companies could benefit greatly from Rails, but only those companies that started with Rails when they were small. Big companies have too much existing data that doesn't fit into the nice clean Rails conventions, and aren't likely to reorganize to the point that they could devolve responsibility for data to the various app teams.
Anyway, food for thought.
posted by at 5:20 PM
0 comments
