Have you ever been on a grails/groovy project that failed because of
- limitations/faults in the technology itself
- the grails/groovy learning curve
Here was my response:
Professionally, I have been a part of seven large Grails applications (+ more smaller endeavors). Of those seven, three of them were moving to grails from another framework, two due to failures with other teams/technologies and one was a Spring to Grails migration.
None of those seven failed because of Grails – in fact – the clients were very happy with the speed of development. Especially the rescue missions that had *very* tight timelines. At one startup we had a quite substantial Grails app that had a Flex front-end. When developing new stories, we found that the Flex front-end took ~80% of the time whereas the Grails components took 20% of our time and were very reasonable to test and maintain.
I’m not saying that we didn’t run into issues in learning curve or even issues/intricacies of Grails itself, but rather that we were able to make excellent progress and address those issues. The community and open source nature of both Groovy and Grails turned out to be extremely helpful when addressing technical challenges.
On one of the projects that had a very tight timeline most of the developers weren’t even Java developers, but had done some Django, PHP, RoR experience. The project was quite successful. We were able to accomplish more in less than a month then another firm was able to do in six months before declaring failure with another framework.
To add to my response, I would say that since testing is a priority and a first class citizen in Grails, it definitely added to the ongoing stability of the projects over time. The sections of code that were tested typically ended up being much more coherent and stable over the course of the projects life.
How would you respond?