Actually the suite of tools we built were only used internally and not open to public — except for some clients. We did not try to build a public web site or a service with it.

One thing I didn’t mention is that working with Rails gave a boost in motivation to the whole team; and we needed that.

I’m glad you keep reading my blog.

Concerning the point of management I guess you’re right, but unfortunately these two projects were not the only one to suffer from management issues — it was not tied to using Rails.

Within these projects I tried to do my best to guide project managers into defining small iterations with clear objectives. Unfortunately they kept trying defining all possible situation for the software and left developers with unanswered questions instead of focusing on steps.

It’s hard to make people think in terms of agile methodologies especially when the waterfall process is not even understood. They fall into a trap where defining the whole product was too complex and where prototyping should have been very helpful. Just too bad, but a classic story.

Concerning the Twitter debate you mentioned maybe I should reply in a separate post but anyway. Scaling is something complex that will change the shape of your hardware and software system, there is no magic and no automatic way to absorb such sudden peak of traffic. If you remember well, the architecture of the system we both worked on have been redesigned 3 times to cope with performance and load issues. Having used Java EJB or Oracle Clusters didn’t help that much regarding the nature of our application — we had to dig in the code and remove frameworks.

It’s no surprise that the Twitter team had to change and tweak the system to remove bottlenecks — that’s part of the job. Rails help you to put you app quickly on the market and that’s the most important. Scaling is a different step in the life of your application and chances are that you will always have to make tradeoffs whaterver the technology or framework you use.