Thinking Of Adopting Groovy and Grails? Do It Now!

Rob James is the CTO of Aegeon and one of the earliest adopters of Groovy and Grails for real world software. In this interview with IndicThreads he tells us why Aegeon chose Groovy and Grails to build their enterprise web2 & social networking product, Spaceo.us. He talks of the challenges in getting web2 and social media ideas into enterprise software. He also shares when one should consider using emerging technologies and how to go about adopting them.

Harshad Oak >> Hi Rob, Welcome to IndicThreads. Could you introduce yourself to our readers?
Rob James >> Sure, my name is Rob James, and I have been involved in technology for about 20 years now. The last 10 of which I have been primarily working within Web Innovation, which includes product development, consulting services and project delivery. I have an engineering background, but over the years worked a lot in User Interfaces and Usability, and more recently in social platforms emerged from Web & Enterprise 2.0. I also have a keen interest in the business side of technology and have been involved in several startups. Most recently, I was the CTO of Aegeon and worked on developing the Spaceo.us product.

Harshad Oak >> Could you tell us more about Spaceo.us?
Rob James >> Spaceo.us was really developed out of a couple of products we were working on for customers. The products were next generation directories, that provided features that we had become familiar within Web 2.0 applications (such as tagging, commenting and voting) into a traditional directory. We soon realised that the directory that we were building could be used as a directory of any type of information, and soon the product evolved into a new type of Portal. Today the product is essentially a next generation portal and knowledge management platform with mashup capabilities.

Harshad Oak >> Spaceo.us talks of bringing social networking to the enterprise. How did you go about building it?
Rob James >> As mentioned it was essentially an evolution of products. But in its early iterations it was a basically a wiki based directory (Imagine a traditional yellow pages directory with the ability for anyone to edit the content). We started by prototyping this, but we also wanted to make sure they we made it as lightweight and robust as possible. We had  small team prototyping the concept, and when we got that right, me moved towards a more robust deployment and added additional features. Using Grails and Agile methodologies, we were able to quickly iterate and test new features in the application. This process took about 9 months till we got to the stage where we were doing pilot implementations for our customers.

“Using Grails and Agile methodologies, we were able to quickly iterate and test new features…”

Harshad Oak >> What technological challenges did you face in building Spaceo.us?
Rob James >> More of the challenges were cultural than technological. Because most organisations didn’t really have the maturity or sophistication to start introducing social networking within their firewall. The major technology challenge was that we wanted Spaeco.us to be able to integrate with many existing business applications, which meant that we needed to almost take a SOA approach to our APIs because we wanted to make this as simple as possible. Everything about the Spaceo.us architecture is lightweight to make it as flexible as possible. But the issues are that its never really that easy in practice, and there is always work to be done with when doing an implementation with a customer. But we have never had an issue that we couldn’t solve.

“The major technology challenge was to integrate with existing business applications…”

Harshad Oak >> You have utilized several emerging technologies in Spaceo.us. Was this because you felt that traditional technologies were somehow limiting?
Rob James >> Since this was “greenfields” project and we were starting from scratch we felt that we had the luxury of picking whatever we liked. I think that by using emerging technologies we have the advantage to leverage new innovation and techniques. And this a huge benefit. It allowed us to develop and innovate quicker and introduce new features that these technologies allow. There is always the benefit of reliability when using more traditional technologies, but in today’s market place it is important to be innovative. It is much like being expected to use traditional steels and alloys if we were to build a Formula 1 car. The team that is using latest carbon fibre, kevlar and ceramic techniques is likely to build a better car. On a personal note for me and my team, it made it more interesting and exciting for us all to be working on new technologies and languages – always good to be learning something new.

“It’s like building an F1 car with traditional steels and alloys instead of carbon fibre…”

Harshad Oak >> What were the special features of these new technologies that got you to use them in our product? How did you and your team go about adopting a new programming language like Groovy?
Rob James >> A lot of the “bang for buck” benefits came from features that would usually take a lot of work to create. Things like RSS feeds and Domain modelling. By using languages like Groovy and platforms like Grails, these things became quite easy to do, which meant we could focus on the more important stuff. But I think the biggest benefit was the realisation that we could spend more useful time building the actual application rather than working on plumbing code, and that was a nice feeling. With Groovy, the great thing was that in many cases the team could transition slowly, they could continue creating classes and use the same methods they did with Java, and as time progressed and they got more comfortable, they could introduce more of the Groovy concepts and language specifics. This certainly was an advantage for us when choosing Groovy over languages like Ruby.

“Using Groovy & Grails, we could spend more time building the actual application rather than working on plumbing code…”

“We could transition from Java to Groovy at our own pace…”

Harshad Oak >> How tough was it to sell the idea of using relatively new technologies like Groovy and Grails? What’s been the response from your team and your customers like?
Rob James >> It was a bit of a challenge to get the whole team across. Although most of them had a lot of experience with Java, there was still the challenge to make them understand the benefits of using Groovy/Grails. Mainly that was because of the uncertainty, and the fact that Grails was still in its early stages of being a platform when we first started the project. It is certainly far more mature now and the team loves working with it. We felt that customers weren’t really impacted by our language choice, the only time this really became the case was when our customers wanted to do some integration work into our platform. But even though we were using Groovy and Grails, to them it was all familiar under the covers, because of technologies such as Hibernate and Spring, so it was never an issue.

“With Hibernate & Spring under the covers, integration with our Groovy & Grails platform was not a problem…”

Harshad Oak >> Many of our readers might have arrived at this interview while searching for Groovy and Grails adoption case studies. What’s your advice to those considering adopting Groovy and Grails for their next product / project?
Rob James >> In short – DO IT! We found that there was some barriers that we had to overcome initially, but the benefits far outweighed them. We could develop and innovate much quicker, and the team was able to adapt very quickly. You still need to make sure you are doing all the right things with your planning, design and architecture, but it does mean that you can spend less time writing plumbing code and more time writing functional code that adds value to your application.

“With Groovy & Grails there were some barriers that we had to overcome initially, but the benefits far outweighed them…”

Harshad Oak >> Do you think users should mix and match Groovy-Grails with traditional JavaEE techniques?
Rob James >> Yes, in fact we did so with our product. And it is easy. Since Grails is Spring under the covers, it is so easy to wire Java into it. There is many ways of doing this of course, but we generally tried to do it as cleanly as possible by using much of the underlying architecture. In one pilot implementation recently, we needed to use some EJBs to directly integrate into the product, and we did that quite easily. The Grails framework also allows that to be done very neatly so you can manage your deployments.

“It’s easy to mix and match Groovy-Grails with traditional JavaEE techniques…”

Harshad Oak >> As a real world user of Grails, what are the features that you feel are still lacking in Grails and you hope to see in a future version?
Rob James >> I think Grails has grown quite a lot in recent times, particularly with the 1.1 release. Prior to that, I though that the testing was one area that needed improving, but that is a lot better now. Being a User Interface person, I think this area can be improved. Although it is infinitely better than some platforms, I think that the flexibility that multiple Javascript libraries and the plugins bring, ends up being a messy rendering of HTML to the browser. This could be done better. Finally, I think the one area that definitely needs improvement is tooling. By far the best IDE is IntelliJ, but some work has gone into the NetBeans and Eclipse ability to develop Grails and Groovy applications, but I would like to see some more effort put there.

“Grails tooling definitely needs improvement…”

Harshad Oak >> Thanks Rob for this interview. Best wishes for Spaceo.us
Rob James >> My pleasure and thanks for the opportunity.