Why I’m not using Groovy at work

Posted on December 14, 2009. Filed under: Grails, Groovy, Uncategorized | Tags: , , |

A disclaimer: this blog is based on my personal failures with getting Grails accepted in our company. So, no, this is not the holy grail into dropping your EJB, Struts or Java toolkit to get groovy with Grails, but maybe you can learn something on how NOT to do it, and post some comments on your experience.

2.5 Years ago, I got my first cup of Grails. It was some time before the Groovy/Grails Exchange 2007, which I visited consecutively. As a result of that visit, I had Graeme Rocher over to our company to give a presentation about Grails (almost 0.4 at that time), and I expected the rest to follow naturally (the rest being: drop all our Java development and take up Grails for all of our web development). I was a little naive in that, I experienced the couple of months after that. Not even did we not drop all our Java development: we dropped none, nor did we picked up any of the cool features Groovy or Grails offered. Instead, people went crazy with frameworks like Wicket, SEAM and other cool stuff, like..ehh…EJB’s…

However, in my spare time I never left Grails and I used it for a lot of prototype applications, especially because the ease of setting up a complete project with Spring/Hibernate integration, etc. And also because it’s just fun to use the power the Grails framework harnesses. Anyway, I never could convince people to seriously use it. I inspired some people to use it, but only for short periods. The lack of IDE support didn’t help in that, and with the thousands of frameworks around, you’ve got to make a choice somewhere. However, I haven’t given up on Grails, and I still try to use it as much as possible. So, when I started for myself in April as an independent (though I do favor certain technologies!) consultant, I thought: this is my chance! I can now focus on Grails technologies. However, even though I’m not quite inexperienced with Grails, I found it hard to find a good (well, any actually) project which was open to Grails, so I found a different project, in which I could focus on other things (like ATDD/TDD, XP, and other quality related things).

However, then, all of a sudden my manager showed some interest in Grails (might not be the best reason to use Grails btw, but it’s great that this is without any resistance!), and we decided to take on a project in Grails. There, the problems started. (Note: I don’t blame anyone in this, except myself: I should have used a different approach. That’s part of reason for writing this blog, to prevent you from making the same mistakes).

What I did first, was tell a little bit about Grails to explain the team how Grails works. That was actually my first mistake. I should have told them lots, lots, a little more, and everything again after that. I thought the transition would be easy, but they were struggling with the framework and the language. I didn’t expect this, to be honest. My expectation (and experience) is that Grails is easy to start with. Get a book, read the documentation, and your ready to go. We built a good prototype, got great feedback on it! However, the old habit kicked in.

Building Grails
First, we tried to build our Grails application with Maven. Bad idea, since it caused some nasty challenges, like getting the code coverage to appear, and getting come quality metrics with tools like CodeNarc. However, you’ll still have to do your (transitive?) dependency management, releasing of software, reports, etc, so there’s something to say for using Maven. It didn’t quite work for us, however, and we spent quite some time into bending it into something which worked for us, which failed. I still haven’t found a viable alternative to Maven. Gradle is nice, Ivy + Ant/Gant seem okay, but that’s not nowhere near the power (I wouldn’t say flexibility) I got with using Maven. I do not, however, make this a Maven vs Whatever Build Tool discussion. I just happen to like Maven for it’s reports, plugin integration, dependency support and modular structure.

Then I also had to overcome the resistance of some of our team members to dynamic languages. Some people prefer the (fake, IMO) safety a statically typed language provides with it’s compilation process. Well, there’s no helping you if you do an Integer.parseInt(“abc”) in your Java code: it will fail just as badly. At runtime. That’s why we write tests, to cover cases like this. This is true for Java, and it’s just as true for Groovy. However, there was still a lot of FUD about Groovy’s usage in bigger projects regarding refactoring, tool support, and even performance. Well, to be honest: I have no idea how easy it is to refactor Groovy code, but, with less code to write, there’s less to refactor. While this might be a bit short sighted, I feel it holds true for a lot of cases.

The tool support deserves a paragraph on it’s own. Eclipse + Groovy was not a good combination. At all. It was bad, worse, and even a bit worse than that. Even if you are the genius to get it to work (or would I say madmen, since a genius would choose a tool like NetBean or IntelliJ, or, heck, TextMate), you still wouldn’t be able to run a decent unit test in it. Did I mention refactoring? I didn’t, for a good reason: No Support For Refactoring. Let me rephrase that: No Support For Refactoring… in Eclipse. Then why choose Eclipse, and not a great tool like IntelliJ (I’m referring to the 8 release) or NetBeans you might ask. To be honest: I have no idea. I don’t use Eclipse. I’ve used IntelliJ for the last 5 years, and only recently I’m switching to SpringSource Tool Suite because of JetBrains’ ridiculous decision to not show module dependencies in the project view. I hope they get some rest after the release of IntelliJ 9, and see the light to put it back in. Until that period, STS is a really good substitute, and has excellent Groovy and Grails support, which is getting better each day!

The right approach?
So, if I would introduce Groovy or Grails again at my work, I would:
– Pick the right people. People who are not intimidated by a dynamic language, but who have the discipline to use it right.
– Pick the right people. People who are prepared to make a switch. To switch from IDE, switch from build tool, switch from language.
– Pick the right people. People who have the mentality to make it work, overcome challenges and share their findings.

It wasn’t intentional to put ‘Pick the right people’ there, but I think that this is the critical factor to make it work. Make it work from within the team, and make it work from outside of the team (IT operations, Management, etc). I’m looking forward into hearing your responses to this. I hope it doesn’t sound to bitter, cause I’m not. I just made the wrong choices with a partially not-suitable team. It’s my mistake, and I don’t blame anyone but me. I just hope people can learn from my experiences, and the post from Marc Palmer was just the right incentive to finish this post. I hope it helps!


Make a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

12 Responses to “Why I’m not using Groovy at work”

RSS Feed for Don’t mind the language Comments RSS Feed

I got the same feedback from our company when we tried to put our hands in Groovy. We haven’t tried Grails though.. but since our programmers are pretty much hard wired for statically typed programming languages like Java, they’re not in a position to appreciate the freedom we get in using dynamic languages. It is this uneasyness, which forces them to think that moving to groovy actually increases risk.

In our case, we observed that the reason we couldn’t adapt to groovy into mainstream development is because of time constraints. So, we use it right now only as our build tool.

Ah, that reminds me of the comments I always get from JSF users trying to convince me JSF isn’t so bad if only I would just try harder 🙂

Well, I don’t think that comparison is quite fair and I think you know that 😉 However, you might have a point there. A good framework sells itself, a bad one doesn’t. However, IMO, the fear of change is playing a bigger role here than the quality of the framework.


“since our programmers are pretty much hard wired for statically typed programming languages like Java, they’re not in a position to appreciate the freedom we get in using dynamic languages”

Speaking for myself, I have some experience with dynamic languages, enough I feel to make an informed decision, and while I do appreciate the flexibility and in general terseness of such languages, I don’t think they are fit for working in larger teams, especially not when – like in my environment – you regularly hire short term contractors to help out. I’m not saying it can’t be done, but I find it suboptimal. And even for personal projects I won’t automatically prefer dynamic languages, just because I don’t feel as productive in them. Sure, some things can be done with (a lot) less code, more elegant, etc, but otoh, tooling support is so much poorer (so instead of using my IDE to navigate through APIs I’m using I’m thrown back years and have to have a browser with API documentation/ google open next to my editor.

Don’t get me wrong, I don’t think static typing is the answer to everything, but I think dynamic language fans (like FP fans) are a little bit too automatic in assuming that when people prefer statically typed languages, it is because they are scared/ stubborn (hardwired) in their old ways/ not smart enough/ whatever… some people may actually have weighted the pros and cons and decided it wasn’t for them.

Well, I feel in this case I’m sort of a lucky guy.
I was hired in february to develop a web application in a bank environment. I came from dynamic languages (namely Python) and I did not have any solid experience with java or Groovy. After a couple of weeks of searching for the best framework (the one that could get the work done, or at last the most part of it, in about four months) and after a look at other applications like opensymbolic we decided that we could make it with Grails. I started learning from my own mistakes and now I have made a solid experience with it. Meanwhile we developed another couple of Grails apps that will be distibuted nationally wide. I think that freedom of choice and a bit of boldness at that were the most important factors for Grails choice. However now I’m refining my experience to get the most out of it and I’m having a lot of fun developing in Groovy and Grails, converting existing apps to it.
Finally I would say that Grails HAS flaws, and it may not be the right tool for everything, but my experience with it is definitely positive.
Maybe I was in “the right people” for those projects, who knows? But I still recommend Grails at least for a try whenever I have an occasion.

Freedom of choice++ 🙂

Manuel, also thanks for the reply. I totally agree: Grails also has it flaws, bugs, etc, and like Eelco says: dynamic languages do put you back in time regarding IDE support, code completion, etc, etc. But, after using Grails and Grails for a while, I find it harder and harder to get my satisfaction out of writing Java code. I focus on DDD quite a bit, and DDD has the concept of DTO’s, Value Object, Events, Command, etc. Creating this in Java is no problem, but it always involves the ‘generate setters and getters’ button in your IDE. The same for loops in your code: how often do you go through a loop, do something with each item in list, and return it in a new list?
I agree that both might not be ‘the’ reason to switch to a dynamic language, but the code your write is much more elegant than the Java equivalent. I’m not even talking about DSL’s (pro’s and cons in that), Metaprogramming (pro’s and cons in that….), etc. When used with care, these are really powerful techniques. You just have to know to what extend you’re going to use it.

PS: I’m a consultant too, but I hope I have some sanity in when to use it, and when not. My personal goal is to write maintainable code, and somehow I find that goal hard to achieve when people inject methods to classes everywhere. With great power… 😉

You are right. Having “the right people” is key! You need people who are not intimidated, are not afraid of change and are passionate about what we do. I have presented Groovy/Grails to quite a few colleagues; some are excited and are working with it the next day, some think it is cool but don’t really give it a try and some just complain because it is just another Java technology to learn. Thanks for sharing your experience.

I have one by one convinced my team to start new projects in groovy / grails. With all of them I have seen the exact same adoption curve.

First they are intrigued by my demonstrations of productivity, showing features of both groovy, grails and especially gorm.

As they begin to use the framework they hit strange errors, almost always caused by something they have done wrong due to being new to the framework. It is critical to spend time helping / coaching during this period as the adopter is looking for reasons why this technology is flawed. You must check in with them often to see what problems they are having.

It is also critical to help coach them with best practices durring the first couple of months. If they are nervous about or having problems with dynamic typing point out and encourage them to strongly type variables in groovy…..

With in 90 days the new user will be comfortable in the framework and language. They will gradually move from being skeptical to being excited about the framework. The bugs and idosycracies in grails still will occasionally frustrate them, but they now realize the good parts far outway the bad parts.

hey you guys are scaring me. I am just starting and trying to decide on groovy/grails or ruby/rails I don’t do Java I thought maybe Grails had a bit more stability as Rails is all over the place.

Hi Fousto,

Could you explain what scares you? And what do you mean with Grails’ stability?

Thanks, Erik

Having “the right people” is key! Why don’t they put the “right” people into Grails Project development?
I’m getting tired of its bugginess…

Where's The Comment Form?

Liked it here?
Why not try sites on the blogroll...

%d bloggers like this: