Leveraging Model Driven Development

Achieving efficiency in the software development process is one of the key motivators every team should strive for. Efficiency can be measured in a variety of ways. The most obvious measurements are cost, project timeline, and the feature set that can be implemented given the first two. In a sense, it boils down to the old project triangle (remember: pick any two of the criteria).

In essence, there is a trade-off between quality, timeline, and cost. For example, reducing the timeline at equal costs reduces quality just as implementing at a faster pace reduces quality. Yet I argue that the triangle approach is not necessarily valid anymore. Traditional development processes have clearly shown that just enhancing the timeline on a project to put special care into the design does not actually lead to higher quality software – quite the contrary.

Yet more dimensions are at play. The number of defects (“bugs”) found in a particular software directly translate into cost and time, especially when found late in development cycle, creating a dependency between testing quality, time, and cost. Inefficient software design increases the cost of introducing new functionality as requirements change and a lack of refactoring capabilities sooner or later lead to the need for a full re-development. The problems are amplified when the software spans multiple independent subsystems, which is often the case in modern web architectures which span across content management systems, web services, search engines, commerce engines, custom web applications, etc.

Agile development methodologies have tackled many of these problems in great detail through test-driven development (TDD) and time-boxed iterative release cycles. This article discusses a number of tactics you can deploy in addition to what you find in your agile toolkit: To speed up development and tackle complex problems with smaller teams in less time leveraging the key ideas of Model-Driven-Development (MDD).
Read more

Introducing Grails

It was Tim Bray, who in his predictions for 2008 mentioned that “Rails will continue to grow at a dizzying speed, and Ruby will in consequence inevitably become one of the top two or three strategic choices for software developers”. Indeed, in my eyes the rails paradigm which blends well-known best-practice patterns such as MVC web applications with the notions of Coding by Convention and Don’t Repeat Yourself doesn’t only speed up and simplify development, but also keeps your code base clean. There are no more tedious configurations files which all repeat themselves yet have the touching fingerprint of every developer’s e. Developers can focus on the most important issue at hand: the functionality. That’s why I’ve always been a huge proponent of Ruby and Rails.

But why Ruby?

With a fairly high adoption rate for Ruby on Rails, some problems have been discussed across the internet (follow this discussion, for example):

• Performance, especially in large installations
• Interoperability issues with other applications / technologies
• Deployment onto existing infrastructures and application servers

What other frameworks are out there that provide the same benefits? For today, let’s dive a little deeper into Grails.

Grails

The Grails project (formerly known as Groovy on Rails) started in July 2005 and the project just recently announced the long awaited 1.0 release on February 18, 2008. Grails is built on top of the J2EE stack and combines the best-of-breed tools Hibernate, the Spring Framework, Groovy Scripting, as well as support for my favorite IDE, Intellij Idea (no worries, Eclipse works too). All mature tools and languages that have been used in the Java community for a long time now. Consequently Grails provides:

• Lower learning curve for J2EE developers
• Easy integration points with existing and new Spring and J2EE applications
• Enterprise deployment of grails applications as a WAR/EAR file
• Similar performance to a Java application (see performance tests on CodeHaus.org).

Demo

Let’s dive straight into a demo in which we will create a few persistent domain classes and integrate an existing CMS backend.

(Click to view the demo)

Features

The following features are included in the 1.0 release:

• Test-driven development via unit tests and mock objects
• An environment-sensitive configuration mechanism out of the box
• Ruby-on-rails like build and development command line tools (that can create war files)
• OR-Mapping via Hibernate (with full support for all Hibernate-supported databases)
• The ability to weave in advanced Hibernate functionality and provide custom OR-mappings if needed (for that remaining 5% of the functionality that require special tuning)
• An MVC web-layer based on GSPs (Groovy Server Pages) which includes custom taglib and sitemesh support
• Ajax support (Grails ships with Prototype but has plug-in support for Dojo, Yahoo UI, and Google Web ToolKit)
• Internationalization Support (Does Ruby do this nowadays? :))

Caveat Emptor?

Yes, the Grails community just released version 1.0 in January 2008. Yet the framework has been in the works for about 2½ years now and I was quite impressed with the amount of features and finesse already contained. The foundation of the framework is built on top of well-established open source frameworks which should minimize the risk of using such a new library.

Would I recommend Grails for a huge enterprise project? Probably not. But I would wholeheartedly recommend every developer and architect to look at this great alternative to traditional web development.

This is a cross-post from the Avenue A|Razorfish technology blog.