Graeme has taken the time to respond to some of the comments floating about in the blogosphere about the performance of Grails vs Rails. This benchmarking comes out very favorably for Grails. In nearly every case, the requests per second and mean response time come out with Grails performing better than Rails. And in some cases, Grails literally blows Rails away (140 vs 35.5 requests/sec on the create test!!). The max response time for Grails is higher in nearly every test case, but this is completely understandable as Graeme points out. I also wonder if he took note of the fact that Grails is always going to be slower for the first hit, but over time will speed up due to the nature of the JVM.

It’s important to keep in mind that Grails has yet to be optimized much (or at all), whereas Rails has been around longer and has been optimized much more. This is the part that makes me feel the best, actually, because it means that there are probably a lot of places where relatively simple changes can improve the performance of a Grails app significantly. Add to that the fact that in Grails you can always drop down and write native Java to increase efficiency (vs. having to write C in Ruby/Rails) and I think it’s clear that Grails is at the very least on par with Rails and likely has even better performance characteristics.

The (un)conference event that is minnēbar (aka Barcamp Minnesota) has found it’s venue in Saint Paul’s Lowertown area in the “Railroader Building”. The date is set for Saturday, April 21st - festivities to begin at 9am.  Refactr will be well represented at the event with Ben sharing MC duties and presenting on a topic relating to either design or the agile method (as opposed to combining the two at last year’s minnēbar). Jesse and Scott will likely tag-team on a presentation in which they build an application in Groovy and Grails in 20 minutes.

If you are interested in attending this year’s event be sure to add your name to the wiki. It is a great way to learn a lot and participate in some great discussions with the best and brightest in the Minnesota tech and design communities.

Colleagues, clients, and even friends are often astounded that we say we prefer shorter project engagements, of let’s say a month to two months, over longer “more secure” (read “fat”) contracts. Here are a couple reasons we like shorter gigs:

1. We can get a lot accomplished in a month or two. In fact, we don’t think there are many projects we cannot bring to a solid release state within this time frame.
2. We believe that a month or two off between two month development and release cycles allow our clients a chance to regroup and re prioritize new endeavors based upon business value. (Of course they can do this at any time during the engagement as well, but it may be hard for them to keep the backlog full for us for more than 2 months at a time) And, what this post is about…
3. We don’t like to pad our estimates.

Padded estimates, in case you are wondering, i sjust a different way of saying fixed-bid. All fixed-bid work attempts to accommodate the unknown and builds in a “slush factor”. To a large extent the fixed-bid project - all fixed-bid projects…

…are inherently inaccurate;
…promote distrust;
…perpetuate the idea that software development is painful.

This is not to say that all the folks providing such proposals are not trust-worthy, or are exceptionally bad at estimating. Instead, it is just a fact that all software development projects of any significant scope, contain a certain number of unknowns. Accounting for those unknowns in a fixed-bid proposal requires the budget be padded or filled with statements of assumptions that attempt to cover the developers’ collective asses.

(more…)

Graeme responds to Charles Nutter’s thoughts on using the Ruby language (instead of Groovy) with the Grails framework. I think that Charles has some good points, but I agree with Graeme. With the resources available, let’s focus on continuing to add functionality to Grails itself.

I’m a huge believer in using the tool that best fits the situation, so I think the idea that Charles has about more freedom of choice regarding languages is completely reasonable - especially with the movement toward more languages running on the jvm. However, my preference at the current point in time would be to continue development of core grails functionality and consider integration of other languages down the road.

Marc Palmer has commented on the discussion as well and has some good points of his own. I highly recommend reading all three posts (by Charles, Graeme, and Marc) as they all have some great insights.

Having spent a good part of the past several months talking to companies about agile methods and what it means to be agile, we have found people to be very receptive to the benefits of working in ways designed to emphasize communication, collaboration, working software, and embracing change. At times, however, near the end of a discussion in which a potential client truly seems to be “getting it”, they will ask a question or two that shatters that illusion. Usually it will be about budget and/or project definition and will often involve a request for a proposal in which the cost, time frame, and features to be included are all fixed.

We are getting pretty good at talking people away from that ledge but we still aren’t perfect. The simple answer we could give them would be that because they desire to fix cost, time, and features, there is only one place that remains to flex: quality. If there is anyone who hates cutting corners and producing an inferior product more than software developers, it is clients who rely on such software. Why is it, then, that so many companies believe that you can attempt to hold all the variables of a project constant?

We can talk until we are blue in the face, quote industry experts who have been through the trenches, and point to numerous failures in RUP or waterfall projects we have been a part of but nothing seems to work as well as pointing to big, respected companies that are doing what we suggest. Toyota (practically invented it), Netflix, and Google all use agile methods to accomplish great things. Now we can add Adobe to that list. A recent interview with lead architects at Adobe explains how they changed the development cycle for the development of the forthcoming CS3 product suite and underscores the point about how quality often gets squeezed out of traditional software development projects.

The change we made was going from a traditional waterfall method to an incremental development model. Before, we would specify features up front, work on features until a “feature complete” date, and then (supposedly) revise the features based on alpha and beta testing and fix bugs. But we were scrambling so hard to get all the committed features in by the feature complete date - working nights and weekends up to the deadline - that the program was always very buggy at that point. We’d be desperately finding and fixing bugs, with little time to revise features based on tester feedback.

At the end of every cycle, we faced a huge “bugalanch” that required us to work many nights and weekends again. Of the three variables: features, schedule, and quality, the company sets the schedule and it’s only slightly negotiable. Until feature complete, we could adjust the feature knob. But when we hit that milestone, quality sucked and we had only a fixed amount of time until the end. From there to the end, cutting features was not an option and all we could do was trade off our quality of life to get the quality of the product to the level we wanted by the ship date. We’ve never sacrificed product quality to get the product out the door, but we’ve sacrificed our home lives.

Of course, Adobe is going to say the only “flex-point” in the system was the work-life balance of its employees and that their new product is of the highest quality, but that cannot be true. The late nights and stress involved in this type of “cram-it-all-in” development style inevitably causes a degrading of quality over time coupled with the opportunity cost of additional features (and the underlying value to the business they represent) that cannot be created.

A day can get you a pretty nice RSS blog aggregator. It takes into account post content and only aggregates posts about Groovy or Grails. It has a nice Ajax front-end and to top it off, it was designed and developed in only 24 hours. You can read all about it and even download the source at the developer’s blog.

Do you live in Minnesota? Are you a Java developer? Are you interested in learning more about the “agile, dynamic programming language” that is Groovy? If so, you should check out the Groovy Users of Minnesota (GUM) group.

The group is brand spankin’ new and is having it’s very first get-together at 6pm on Tuesday, March 13th at The Coffee Grounds on Hamline Ave. in Falcon Heights (near Roseville and Larpenteur Ave.) (map). We plan to meet on the second Tuesday of each month, and have set up a calendar (iCal, XML).

Check us out and we can learn more about Groovy and related topics, such as the framework: Grails. We can all share our experiences, techniques, and knowledge to strengthen the rapid software development crowd here in Minnesota. Join us.

*Although we cannot promise it won’t happen, there will be an effort to refrain from trying to use the word groovy in a comical/cheesy** way.

**Humor, like beauty, is often in the eye mind of the beholder speaker/poster.