Tuesday, March 21, 2006
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:
Another bonehead decided to key in on one phrase stating the obvious that no one negotiates a contract with a vendor named Ruby which of course missed the entire point. If other architects are not currently championing Ruby and the large vendors such as Sun, BEA, Oracle, IBM, etc are not currently Ruby and even large integrators aren't. then the only ones that may champion Ruby are vendors that enterprises may not be using to develop enterprise applications hence the contract notion. You can get it twisted by focusing on contract negotiation as an agilist or you could attempt to figure out how the large vendors and integrators can increase their margin by adopting it.
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...
Here are some additional thoughts / points in no particular order that folks should seriously consider:
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 needs to be supported on more platforms? The attention seems to be only on Windows / Unix / Solaris and easier to reach? What about the other platforms used within the enterprise?
9. Does anyone agree that the notion of packages / namespaces should be a part of every modern language?
10. While everyone has their own definition of the word enterprise and therefore it is somewhat overloaded, I have in the past used it to represent a sales model and how software is sold. Some folks would argue that product X is not enterprise ready when they are merely indicating that there is no one available that can do powerpoint to my audience. What could the community do to address this in order to increase adoption?
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?
I suspect there will be lots of folks spending time countering all of the above thoughts and of course will not even pay attention or even from an open minded perspective consider what I am about to say. Anyway, I figured instead of going on a rant, I would volunteer to help the Ruby community step up so that enterprises wanted to use it and offer my guidance if you are willing to consider it from an open mind. The following things need to happen though:
1. We need to get a port of Ruby running on Z/OS so as to offer competition to Rexx.
2. I figured it is important in the name of transparency for me to declare exactly what I will get out of this effort after all nothing in life is for free. One perspective that I have been working hard on changing is that the open source community is all about software vendors. The magazines never seem to want to cover stories of large enterprises and their contributions to the open source community. If you could get Jon Udell from Infoworld to do a story on Duke Energy and their contribution to the community of a wonderful .NET framework and they would be willing to put a mugshot of a Duke employee on the front cover, I will no less than 48 hours expose a mainframe to the Internet that will allow for the first bullet to begin.
3. I support the agile community in some aspects but not in others. Over time I have come to realize that the principles are sound, I just sometimes question the motives of their founding members. The Six Sigma and CMM community for example, are huge nowadays because their founding members allowed it to grow beyond them and didn't put any artificial constraints on it. The agile community has reached its crest and cannot grow any larger because it would require its founding members to let it grow beyond them. As a test, ask a Six Sigma and CMM practitioner for the founding members names and I suspect they couldn't tell you without researching it first. Not knowing the founders is a good thing as it is a testament to one's ability to grow. I ask that the Ruby community not make the same mistakes as the agile community in this regard...
| | View blog reactionsI 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...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.
Another bonehead decided to key in on one phrase stating the obvious that no one negotiates a contract with a vendor named Ruby which of course missed the entire point. If other architects are not currently championing Ruby and the large vendors such as Sun, BEA, Oracle, IBM, etc are not currently Ruby and even large integrators aren't. then the only ones that may champion Ruby are vendors that enterprises may not be using to develop enterprise applications hence the contract notion. You can get it twisted by focusing on contract negotiation as an agilist or you could attempt to figure out how the large vendors and integrators can increase their margin by adopting it.
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...
Here are some additional thoughts / points in no particular order that folks should seriously consider:
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 needs to be supported on more platforms? The attention seems to be only on Windows / Unix / Solaris and easier to reach? What about the other platforms used within the enterprise?
9. Does anyone agree that the notion of packages / namespaces should be a part of every modern language?
10. While everyone has their own definition of the word enterprise and therefore it is somewhat overloaded, I have in the past used it to represent a sales model and how software is sold. Some folks would argue that product X is not enterprise ready when they are merely indicating that there is no one available that can do powerpoint to my audience. What could the community do to address this in order to increase adoption?
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?
I suspect there will be lots of folks spending time countering all of the above thoughts and of course will not even pay attention or even from an open minded perspective consider what I am about to say. Anyway, I figured instead of going on a rant, I would volunteer to help the Ruby community step up so that enterprises wanted to use it and offer my guidance if you are willing to consider it from an open mind. The following things need to happen though:
1. We need to get a port of Ruby running on Z/OS so as to offer competition to Rexx.
2. I figured it is important in the name of transparency for me to declare exactly what I will get out of this effort after all nothing in life is for free. One perspective that I have been working hard on changing is that the open source community is all about software vendors. The magazines never seem to want to cover stories of large enterprises and their contributions to the open source community. If you could get Jon Udell from Infoworld to do a story on Duke Energy and their contribution to the community of a wonderful .NET framework and they would be willing to put a mugshot of a Duke employee on the front cover, I will no less than 48 hours expose a mainframe to the Internet that will allow for the first bullet to begin.
3. I support the agile community in some aspects but not in others. Over time I have come to realize that the principles are sound, I just sometimes question the motives of their founding members. The Six Sigma and CMM community for example, are huge nowadays because their founding members allowed it to grow beyond them and didn't put any artificial constraints on it. The agile community has reached its crest and cannot grow any larger because it would require its founding members to let it grow beyond them. As a test, ask a Six Sigma and CMM practitioner for the founding members names and I suspect they couldn't tell you without researching it first. Not knowing the founders is a good thing as it is a testament to one's ability to grow. I ask that the Ruby community not make the same mistakes as the agile community in this regard...
