James McGovern::thought leadershit
So, James McGovern is STILL talking about Ruby not being ready for the enterprise. In his latest post, defending himself, he first comaplains that things are taken out of context by people only taking one line and not looking at the whole context, so I am taking this as an opportunity to quote all three blog posts and reply inline to the entire thing:
I apologize for the length and overall “bileness” of this post. This is just an ingoramous confronting a fellow ignoramous. 
From the first blog post:
Large Enterprises and why they don’t care about Ruby
The funniest thing is occuring in the blogosphere. Lots of folks who write for industry magazines have jumped on Ruby, yet you will never find a single large enterprise that is even considering it. Ever wonder why?
Yes…
All we’re asking is that you stop spreading misinformation about the current state of dynamic languages to the press, analysts, and your customers. This does not require you to champion or otherwise support these technologies - just stop lying about them.
Hmmm. I would ask the same thing of the dynamic community. Right now, you folks are living on hype instead of stating facts. Name one single enterprise application in the ERP, CRM, etc space that either is written in a dynamic language and/or is being considered ported? Name one system Fortune 200 enterprise that has a mission-critical system written in a dynamic language. Of course, you can’t.
I think James, you are right here. Of course, Ruby has only just now started its accent… How long was it before the above statement was true with Java?
What is sad is seeing otherwise senseful folks get it twisted by talking about the speed in which development occurs when it all reality, the costs to develop an application may only equate to 10% of the total cost of ownership. I wonder if these folks have ever studied software engineering economics? What is even sadder is that many of these folks believe in agile software development yet refuse to consider costs over the lifetime.
Again, there is some truth to this… maintenance is where the expense is. That is why you try to write easily maintainable code, regardless of the language. Ruby helps facilitate this by (among other things) allowing you to construct a DSL that more closely aligns to your business needs.
I predict that many folks in the agile community are busy bidding on enterprise application development as we speak using approaches such as Ruby on Rails with the flag waving fervor is saying that development is cheaper. I guess the average enterprise doesn’t already have enough languages to deal with and throwing a few more on the pile won’t hurt. I wonder which of the original signatories of the agile manifesto are guilty of leading this irresponsible charge? Thanks agilists for making the enterprise more of a mess…
I bet your right. Can you blame them? How do you think all those other languages got there in the first place? Most likely the same way. And, is it really irresponsible? I mean, they are providing a service with the typical marketing: faster development equals cheaper development (notice I say development here, not maintenance). But, for once, the hype may just be true. Of course, there will be those “insulting” firms that will abuse and totally ruin a project, after using that hype. And of course, this has happened with every other big language trend that has ever existed. Nothing more than the next phase of the “Next New Thing” cycle.
More Thoughts on Ruby and Why it isn’t enterprise ready!
I previously blogged on Large Enterprises and why they don’t care about Ruby and was rightfully accused of bashing folks in the Ruby community but not providing the answer to my original statement. Figured I would set things right…
Excellent! Lets see where this goes!
…um… OK, lets see why: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…
Come on James, have you actually READ one of the books on Ruby? Your comments below (in the next post) belie your statements here. And Agile not promoting learning??? To me that is a core part of agility: constantly learning and improving oneself and ones processes.
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.
For a minute I did not think you were going to mention Ruby at all here, but you got it in at the end… Why would an enterprise NOT choose Ruby? I’m not talking about for every darn thing in the enterprise, but there are certain things that make Ruby (especially when coupled with Rails) a VERY valuable tool to an Enterprise looking for quick TTM.
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.
What you saying here? I’m catching a bunch of different vibes:
1. Enterprise Architects are stupid (they must rely on consulting firms)
2. Industry Analysts make irresponsible recommendations, and are NOT looking at Ruby (sounds like a plus for Ruby to me)
3. Whitepaper mills like Gartner control the future of computing (cause it certainly can’t come from enterprises (see #1))
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.
Now, I believe you may be right on the first part here, probably not too many Enterprise Architects are reading this stuff. After all, they are too stupid to do anything but follow their consultants. But then, could they be thinking about their stategy without looking at upcoming trends in Software Development? I guess maybe your right, they must be stupid if thats the case. I personally do not buy it.
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.
I know a couple that are thinking about it, but not necesarily have blogged about it. After all, not every Enterprise Architect is also a blogger. Also, this goes against your previous item, in so far as there must not be any interest in Ruby (not reading it in magazines…).
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.
And some like to control their destiny. And WTF is this talk about T-Shirts?
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.
Again, this has some truth to it. But then again, that is assuming that the only path forward is by following these big companies. Now, I’m not saying that we shouldn’t be relying on them, but again, some companies like to have some control over their destiny.
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.
OK, even giving that there are more important things then productivity, what you seem to be talking about is more about policy and procedures… nothing you cannot do in Ruby.
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.
I agree here. So why are you wasting your time? (I’m well aware that I am wasting time here) Oh, and where is #10?
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.
Well, I am not an expert (in anything) but I have seen (and believe from my exposure to Ruby) that there are tremendous gains to be made. Especially over “Enterprise” tools, such as EJB.
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.
Where is proof on this? I did a quick Google on Jolt Award pay-off, and scanning the first page am not seeing an expose. Can you point to one?
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?
Are you sure you haven’t dealt with some of these consultants? I’ve heard that ObjectMentor is doing a couple ruby gigs. And IBM Global Services would write anything for anybody, given the right payment plan.
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…
I agree on the transparency. But lets turn the table here and look at you for a moment… whats in it for you to bash Ruby like this?
and finally:
Additional Thoughts on Why Ruby isn’t ready for the Enterprise…
Continuing the thought on Why Ruby it isn’t enterprise ready. Of course, many folks in the blogosphere will pick out a sentence or two and quote it out of context. Don’t get it twisted, consider all points, don’t pick and choose. Although, some bloggers can do so in a humorous way:
I think you will find that I am keep the context, all the way through.
So leadership consists of knowing of whose lead to follow? I guess we can just wait for Gartner or Forrester to establish a conference on jumping off of bridges and McGovern’s leadership will take care of itself.
I guess I should cut this person a break in that they haven’t read prior blog entries to know my position on following analysts. After all, that little search button on my blog if filled with the words industry analyst might not provide a different perspective…
I am sure you are confident to lead yourself into whatever technology you want. I just hope that you do more background research when you actually DO decide on a language. Oh wait, there can be only one language. And as far as reading the rest of your blog, maybe some other time… I really have better things to do than this.
Blah Blah Blah. Ok, I’ll bite. James, your right. Why would a super-mega Consulting firm like those you’ve mentioned want to do anything with Ruby right now? They have their teeth firmly sunk into the necks of many-a Architect that is too stupid (see comments above) to know better? The tides have not changed enough (yet) to warrant them moving to the next victim.
Many folks haven’t figured out that I too am a fan of Ruby. The problem I think the community has is when folks separate what they like from what they will “recommend” and push for the enterprise. In talking with other architects in corporate America, they too have came to the same conclusion. It doesn’t matter if you feel any perspective I state is valid or not, what matters is that others may be thinking the same thing and it is in the best interest of the community to have canned answers to them. Oh by the way, don’t get it twisted and think that every single opinion is my own because that would be highly inaccurate…
James, you are not a fan of Ruby. That is pretty clear by now. And if it were not, then it will be in a few moments. You do not even know what language does. Oh, and I’ve got to admit it: I love the “canned answers” bit… Shows a lot of respect for your “peers”. And, while I am pretty sure most of these are not your opinions, I admire how you stick with them.
The rest of these have been covered completely and thouroughly here, here, here, and, well shit, everywhere. But I did not want to get accused of leaving out context. 
1. Productivity is elusive. For example, if I hire two different insulting firms whom both practice agile methods where one uses Ruby and the other uses Java, I can predict which one may deliver an application quicker to me, but I can’t predict which one will cost less. Let’s say I decide to hire folks from one of the more prominent agile consulting firms who will charge me a higher hourly rate and uses Ruby whereas the other insulting firm who practices Java and Agile Methods but is from India takes a lot longer but has cheaper hourly rates, which one will be cheaper? The real answer is when I receive the “bids” from both parties, they will be competitive. Don’t get it twisted in thinking about my example using folks from India as this would miss the point. The real point is that folks in the agile community cost a lot more than folks not in the agile community even when both are from the same country and have the same types of experience. I may not even have visibility into the productivity games and the insulting firms will want to keep it as margin.
2. Costs within the enterprise are not in software development anymore. Have you seen the electrical costs within most data centers do to all those inefficient but rapidly coded applications? Maybe you have figured out that within most large IT shops that if only 25% of the folks there know how to code then productivity gains here aren’t as significant as say realizing savings from say operations where more folks reside. How does one save on operations costs? The answer is easy, one may choose languages that exhibit better performance and scalability characteristics than one that doesn’t.
3. Continuing the thought, Ruby currently doesn’t realize the above characteristics. Maybe if it added native thread support, this aspect may go away.
4. Another deficiency that Ruby needs to consider is that not everyone on the planet speaks the same language. Enterprise applications (I really should post a definition for this but will save for another blog entry) in many shops and as written by many large software vendors need to support multiple languages simultaneously. Ruby needs to address multilingualization quickly.
5. In my career, I have noticed that folks who know Visual Basic tend to not get multiple threading architectures and will make design level mistakes. Ruby folks as another predictor (different from guarantee) tend to not design (Yes, I know the agile party line here) and are successful in getting applications to work quickly but tend to skip out on long term maintainability. Maybe the best thing that Java folks can do for the Ruby community is to bring more of a software engineering mindset to development.
6. Ruby is going down a path of creating their own Virtual Machine. It seems to me, that they should simply put Ruby on the Java VM and not waste efforts in reinventing the wheel.
7. Ruby should support the notion of being about to be embedded into other platforms vs. simply being standalone.
8. Ruby seems to be missing something that is otherwise fundamental in other languages which is support for Regular Expressions.
9. Does anyone agree that the notion of packages / namespaces should be a part of every modern language?
10. I also couldn’t find the equivalent of instance variables. Wouldn’t that make reuse at an enterprise-level somewhat problematic?
11. Shouldn’t the notion of methods being public, private and protected also be a part of every modern language?
12. Let’s say that Ruby steps up to all of the things I listed above and does so in a rapid manner, wouldn’t that break all applications that used Rails? I believe the answer is that it would cause a trainwreck for any enterprise application that was built on top of it?
13. Does anyone in the community acknowledge that software vendors and even many large enterprises don’t build on top of scripting languages because they don’t want their intellectual property so discoverable?
