Byłem raz na wykładzie Paula Klippa dotyczącym sprzedawania projektów robionych w Agile. Ponieważ wiemy dosyć dobrze, że RoR dobrze współgra z tą metodologią, a jej “sprzedawania” też napotyka opór, głównie “starych wyjadaczy”, to przytoczę kilka argumentów, które on przedstawił, przemawiających na korzyść Agile (i RoR).
Zacznijmy od tego, że każdy produkt (nie tylko informatyczny), charakteryzowany jest przez trzy czynniki:
- koszt (do którego można zaliczyć również czas wykonania)
- funkcjonalność
- jakość
Często w projektach informatycznych zapomina się o ostatnim czynniku. W szczególności klienci mało kiedy pytają o to, czy nasz produkt będzie niezawodny. Częściowo dlatego, że przyzwyczajeni są do kiepskiego oprogramowania.
W kontekście Agile Paul wskazał, że jeśli zafiksujemy dwa czynniki (kosz oraz funkcjonalność), to oczywiście trzeci będzie musiał na tym ucierpieć. Innego wyjścia nie ma. Wiadomo, że oprogramowanie tworzone w pośpiechu jest zwykle dużo gorszej jakości.
Jak to przenieść na RoR:
Czas wykonania - ze względu na to, że dużo typowych funkcjonalności jest w RoR zaszytych (powiedzmy CRUD), a wiele można znaleźć w pluginach, to czas wykonania serwisu będzie krótszy. Na kliencie świetne wrażenie zrobi demonstracja działającego produktu już po jednym dniu developerki. Niech to będzie sam panel logowania i banalny CRUD na jednym modelu oparty powiedzmy o ActiveScaffold. Mniejsza o to, że w php korzystając z gotowych rozwiązań też można coś takiego zrobić. Tego klientowi mówić nie musisz 
Funkcjonalność - w szczególności w kontekście rozwoju aplikacji. Ze względu na w pełni obiektowy charakter rubiego oraz narzuconą domyślną strukturę Railsów, wprowadzanie w nich zmian i dodawanie nowych funkcjonalności jest IMHO dużo łatwiejsze, przejrzystsze, wymaga podejmowania znacznie mniejszej liczby kluczowych decyzji. Dla klienta oznacza to właśnie, że jeśli po zakończeniu projektu będzie chciał dalej go rozwijać (a znacie jakiegoś klienta, który by nie chciał), to po prostu mniej za to zapłaci. Nie wspominając już o tym co w pop. punkcie - pluginach. Raz miałem sytuację, w której trzeba było dodać Captche - wszytko sprowadzało się do zainstalowania jednego pluginu i dodania 3 linijek. Bez ściemy - po prostu zadziałało jak trzeba. Jak znam życie, to np. w jakimś phpowym cmsie, musiałbym nad tym spędzić cały dzień.
Jakość - testowanie to też praktyka Agile, która jest, jakby to powiedzieć, “wspierana” przez Railsy. Jeśli klientowi zależy na niezawodnej aplikacji to powiedz mu, że Ruby posiada najlepszy framework do testowania czyli RSpec (ja sam do niego tak przekonany nie jestem, bo na co dzień używam Shouldy, ale taka opinia krąży wśród znawców 
Zaproponuj mu, że wygenerujesz mu tekstową wersję specyfikacji aplikacji. Oczywiście nie będzie tego czytał w całości, ale jak zobaczy poziom szczegółowości to nabierze szacunku do Twojej pracy Tak samo jak w punkcie 1 - dla innych języków też istnieją frameworki do testowania, ale Railsy naprawdę wspierają tę fazę tworzenia oprogramowania.
Oczywiście pozostaje problem masy - fakt: w Polsce RoR jest niezwykle mało popularny. Możesz jednak powiedzieć w sekrecie swojemu klientowi, że na niektórych uczelniach kształci się studentów w tej technologii (konkretnie na UJocie :), więc jak będzie miał deficyt programistów, to może zgłosić się do mnie
Możesz też wskazać mu, że Polska ciągle nie należy do elity innowacyjnych rozwiązań, a jeśli zainteresuje się tym co dzieje się za granicą, to szybko przekona się, że RoR rulez. Możesz też przytoczyć fakt, że powstało wiele projektów właśnie dla PHP, które kopiują Railsy. Tyle, że kopie zawsze pozostają w tyle za oryginałem.
