ทำไมไม่ใช้ RoR ในโปรเจคใหญ่

ผมเคย post ไว้ว่า จะเลือกใช้ RoR ในกรณีที่ project เล็กๆ
แล้วก็มี comment ถามเข้ามาว่า ทำไมถึงเลือก choice นั้น
ใช้เหตุผลด้านไหนเป็นตัวตัดสิน

วันนี้อ่านเจอ blog ของ Glenn Vanderburg
หัวข้อเรื่อง The Right Team for Rails
เขาเขียนได้ตรงใจทีเดียว

A good Rails team will consist of programmers who know what they should be doing, and usually have the discipline to do it.

The wrong Rails team is one that doesn’t understand those principles and practices. The fact that Rails makes things easy won’t be enough. In my experience, such teams expend amazing effort and ingenuity to do the wrong thing.

กรณีของผม ที่ผมวางแนวทางไว้ก็คือ
ถ้าเป็น developer มือใหม่ เข้ามาในบริษัทฯ
ผมจะยังไม่ให้ใช้ RoR เลย
จะให้หัดใช้ mvc แบบ Struts ให้เข้าใจ framework เสียก่อน
,ใช้ hibernate ได้อย่างไม่เก้อเขิน
,มอง springFramework เป็นเหมือนสวนหลังบ้าน (เปรียบเทียบเวอร์ไปนิด)
ให้ดี ก็ต้องใช้ tapestry เป็นด้วย (จะได้ซาบซื้งกับหลักการ reuse component)
แล้วก็ผ่านการพัฒนา project ด้วย java มาอย่างน้อยสัก 1 project ก่อน
คราวนี้แหล่ะที่พร้อมจะใช้ RoR ได้แล้ว
(ความหมายของคำว่า "พร้อม" นี้
หมายถึงพร้อมที่จะร่วมพัฒนาระบบงานใหญ่ๆ พร้อมๆกันเป็น team)

แก้ไขเพิ่มเติม ลืมบอกลักษณะของโปรเจคไป
โปรเจคที่ผมทำส่วนใหญ่เป็น web application ทีเป็นพวก Data Entry
มี form เยอะแยะเต็มไปหมด (ส่วนใหญ่จะ replace terminal app หรือ client-server
app ของเดิม