Saturday, March 18, 2006
More Thoughts on Ruby and Why it isn't enterprise ready!
The focus of this blog is on Ruby and not on other dynamic languages. For those, they will get their own blog entries. Ruby, to me feels like a trainwreck waiting to happen. So lets list out reasons why Ruby currently makes zero sense for developing enterprise applications...
1. While there are lots of books on Ruby, none of them are good. Most are mediocre and deal with the simplistic aspects of writing software. The publishing community tends to focus on introductory titles and eschew books that are for folks who already know how to program, which constrains one's ability to do anything complex. Of course the agile community, doesn't count learning on the job as part of the cost of a project...
2. For shops that have mature enterprise architecture practices, they simply don't allow insulting firms to propose architectures for them. Of course, the Federal Government does this fatal mistake all the time, so it doesn't surprise me about DARPA. Good EA practices start with not only acheiving cost-savings, enabling the strategic intent but also add consistency. We all know that Government Enterprise Architecture is a big fat joke and has only been successful at realizing adding spending, not enabling our strategic intent and removing consistencies. Ruby will only show up in enterprises were they don't determine their own destiny.
3. Much of the guidance that the enterprises receive come from either big consulting firms such as Accenture, DiamondCluster, Wipro, Bearingpoint and others. If it isn't on their radar then it probably won't reach critical mass. Likewise, the other perspective comes from industry analysts who usually make irresponsible recommendations and oversummarizations of most problem spaces. In this particular scenario, industry analysts aren't even wasting their own time talking much about Ruby. If you happen to see Gartner or Forrester establish a conference on Ruby then it will catch our attention, otherwise we will not pay attention.
4. How many enterprise architects do you think that work for Fortune enterprises are actually reading the magazines that to date have discussed Ruby? A very small percentage. They are too busy thinking about the strategic intent of their own enterprises and many of these magazines are losing their focus and direction by providing a vehicle of meaningful content. Many of us in this space now get our information from each other and the blogosphere.
5. Speaking of the blogosphere. Have you ever ran across a single enterprise architect who is employed by a Fortune enterprise blog about Ruby. I believe the answer is an emphatic no (I don't count). In conversations with several of my peers at work, many of them have used Ruby for outside projects but when asked why aren't they championing it at work are of the belief that there are simply more important issues to talk about. Ruby is somewhere on the list towards the bottom of the pile.
6. Large enterprises tend to like big vendors. Some will be of the belief that it is because they mail us enterprise architects brand new laptop bags with their logos on them (some small truth to this) while others acknowledge that it is all about capitalization. The latter will work itself out over time (or not) but maybe the Ruby community should step up its branding efforts with T-Shirts and other giveaways in places where enterprise folks tend to gather.
7. Those same vendors such as Sun, Microsoft, BEA, Oracle, CA, etc simply can't make money off Ruby. If a business can't make money off it, why would they even care. I am somewhat glad that folks at Sun aren't paying much attention to Ruby as it is important for them to focus on making money and they do so on Java.
8. Enterprises no longer really care about productivity (describing in terms of extremes, so don't take literally) but are more interested nowadays in transparency. With all the legal and regulatory issues affecting many large enterprises the focus has simply shifted away from software development oriented issues to other areas. Saving a couple of developers a couple of weeks on a project can easily be wiped out by a single subpoena from an attorney general and all the legal fees one has to spend.
9. The community needs to get their priorities straight. People, then process then tools in that order. Ruby is a tool. We know of at least one analyst that gets People over Process is what matters. A fool with a tool is still a fool.
11. The productivity argument is lame. Do you know how many times my phone rings in a day with some poorly trained sales guy on the other end attempting to sell me something? Do you know that all of them talk about productivity gains? If any of this were ever true, I would be the only person in IT for my company. We know that productivity simply isn't realizable in the way folks are calculating it.
12. Back to the books, all those books that won the SD Magazine awards are somewhat dishonest. Is it stated somewhere that this award is one that folks pay for? Let's add some transparency which will bring the community credibility.
13. Lets say there is a sixteen week project and the productivity stuff was true and Ruby could save me an entire three weeks which would be significant. Since Ruby is a new vendor and not represented by existing vendors I already do business with, do you think that I will spend more than three weeks in just negotiating the contract?
14. I am one of the biggest supporters of agile methods but I too am not so delusional to know that many of its founders don't practice transparency. One should immediately question folks in the community regarding Ruby and attempt to figure out what's in it for them. Likewise, it would be wonderful if these folks became more transparent on their own. One of the original members of the agile community that I have tons of respect for is Jon Kern. You may have noticed that he doesn't talk much about writing code but focuses in on generating code and is a big advocate of Model Driven Architectures. The future state says that coding will be for the lame and that code won't matter but I guess the agile community didn't get Jon's memo...
Links to this post: