Some portions of this article sounds interesting. May be you have some links where I could read more about this topic?…

In terms of getting large enterprises whose primary business model isn’t technology involved in Ruby benefits Ruby by the simple fact that this demographic represents 90% (The masses) of all IT folks. More importantly, this same demographic has 590% more capital than the 10% that Ruby currently has. Capital allows folks to accelerate the growth, features and adoption of all the hard work the Ruby community put into it.

You should noodle this thought and even if you agree slightly, you should amplify it in your next blog entry…

Only considering that all dynamic language programmers are not loved for their debugging skills….

Byee byeee rails… Enterprises do not need another nightmare like CGI

I have been noodling several things said by David Heinemeier Hansson and James Robertson who are co-Presidents of my fan club and their interesting outsider looking in perspectives on the enterprise. Felt it was not only important to respond to their…..

If you’re looking for ways to explain the value of RoR in enterprise computing, I suggest you approach the question from the point of view of management. They are not interested in the technical reasons why development time can be saved. They are only interested in cost and value.

Several characteristics of RoR contribute to cost control, and may be of interest to managers who have decision-making authority regarding the choice of development tools for enterprise software. You mention several of them in your post - in particular, ‘less code’ and ‘convention over configuration’ directly lead to reduced TCO, and management should be able to relate to them.

Another benefit is the ease with which applications can be made to comply with enterprise standards. By customizing template code, you can ensure all the RoR applications have the corporate look and feel, propagate and handle exceptions in a consistent way, call on enterprise facilities such as single sign-on as required, and many other details that collectively result in substantial TCO savings, especially when you consider the costs of supporting many enterprise applications.

The advantages of live prototyping in front of a customer depend on the corporate culture, the customer’s attitude toward and past experience with prototyping and iterative development, and the nature of the problem at hand. RoR’s ‘generate scaffold’ script may not actually give you the sort of functionality the customer is having difficulty with. They probably understand how a program can access and database and display a page. Where prototyping is helpful is in more complex scenarios where the customer cannot clearly visualize or explain his requirements. I’m not sure this is an especially strong selling point for RoR in the enterprise, because it may not be all that easy to prototype something like that immediately in front of a customer. Walking through a workflow using a whiteboard may actually be more effective in that case.

You mention software factories. The basic model that has been gaining ground is a service-oriented architecture to provide enterprise-wide shared services (probably based on Web Services), plus tactical application development tools that can orchestrate those services and provide customized value-add functionality for end users (probably based on familiar web technologies). RoR fits perfectly into the latter role. This could be an approach to ’selling’ RoR in a company that is building a software factory.

Danny a dutch blogger said something intriguing regarding software development in Ruby that should be considered……