Agile Zone is brought to you in partnership with:

Matt is the Group Leader of Research Application Development in the Research Informatics Division of Information Sciences at St. Jude Children's Research Hospital in Memphis, Tennessee. Matt has been developing and supporting enterprise Java applications in support of life sciences research for St. Jude since 2001. Matt is a committer to multiple open source projects and is the founding member of the Memphis/Mid-South Java User Group. Matt is also a regular speaker on the No Fluff Just Stuff symposium series tour (as well as other major conferences), and his articles have appeared in GroovyMag and NFJS the Magazine. His current areas of interest include lean/agile software development, modularity and OSGi, mobile application development (iPhone/iPad/Android), web development (HTML5, etc.), and Groovy/Grails. Matt has posted 44 posts at DZone. You can read more from them at their website. View Full User Profile

On Gaelyks and Golden Hammers

  • submit to reddit
I had a break in my personal speaking schedule today at NFJS in Minneapolis, MN, and I decided to attend Tim Berglund's talk on Gaelyk. Gaelyk is an extremely lightweight Groovy framework for Google App Engine (GAE). During his talk, Tim asserted that Gaelyk is small because it is focused on solving the small problems. We've gotten very good (in the Java space) at building framework solutions targeted at solving enterprise problems with a relatively large amount of complexity. Because of this, we don't tend to build the quick one-off types of apps (e.g. various flavors of Twitter aggregators) with Java-based technologies. While our frameworks are quite capable of producing solutions to this scale of problem, it's rare that we actually apply them. The inherent complexity in the frameworks tends to get in the way. As an example, look at Grails. Tim and I both "love the Grails," but targeting GAE with Grails is still not a solved problem. The sheer size of the deployment unit (22Mb w/ zero added functionality) and the startup time (often greater than GAE's 30 second limit) still force us to shy away. Gaelyk sits well in this sweet spot, offering a virtually weightless deployment unit and rapid startup. The tradeoff is that any application with sufficient complexity will be extremely painful to develop with Gaelyk. If we enhance Gaelyk to meet those needs, we would eventually eliminate it's lightweight properties.

I say all of that to remind us of the fact that we need to use the right tools to solve jobs. One of the most prevalent antipatterns in software development today is the Golden Hammer. We get so attached to a tool that we feel compelled to use it to solve any and all problems. We get attached to a hammer and everything starts to look like a nail. In that respect Gaelyk is a breath of fresh air. By its very nature it refuses to become your golden hammer.

  • It's extremely coupled to GAE. If you want to target another deployment platform, you're going to do a rewrite.
  • It's extremely coupled to simple and small applications. If you want to build something big, you're going to hurt yourself.

This whole thought pattern quickly carried me away to the world of software development methodologies. We're no less guilty of turning methodologies into golden hammers. Many a practitioner has stood up and hailed his favorite methodology as the silver bullet to solve the software development world. Take your pick: TSP, PSP, RUP, XP, Scrum, etc. Whole businesses and consultancies revolve around installing one of these methodologies into your organization, thus fixing your software development practice.

Perhaps its time we realize that methodology is just as context dependent as technology. Perhaps its time that we examine things like:

  • organizational culture
  • management styles
  • organizational hierarchy
  • problem scope
  • essential complexity
  • team geography
  • etc., etc., etc.

Given that analysis, we pick the methodology that best fits the environmental factors. Is it tenable in your organization to get all of the necessary players together on a single project team in a single geographic location? Then there's a great chance that Scrum or XP "out of the box" will get you where you want to go. Are you sitting in an extremely siloed organization with a great deal of hierarchy and an inherently uncollaborative culture? I'm sorry to say that Scrum or XP will very quickly fall down for you.

I can hear the zealots now: "There's nothing wrong with methodology X! You're just not using it right. You need to change your organization to make X fit!" Unfortunately, in the timespan we're typically given, that's about as easy as shaving the grooves off of a screw to make it a nail. You've got to start with where you are. A great technique then is to leverage the principles of Kanban to help you evolve in a kaizen way toward the methodology you'd like to employ. However, lest you think I'm turning Kanban into a golden hammer, even that might not work! Sometimes you change your organization, and sometimes you change your organization.

In summary, context is king. Give the golden hammer back to Thor, let Gaelyk be Gaelyk and Grails be Grails, and stop trying to shove a Scrum-sized peg into a RUP-shaped hole. That is all.
Published at DZone with permission of its author, Matt Stine.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


David Lee replied on Fri, 2010/10/15 - 9:05pm

 The right tool for the job mantra requires that you know how to use many tools.  The right tool for the job usually turns out to be the tool you know best.  And I think that's ok.  "Right" is subjective.  My "right" my not be yours.  I don't even bother with "right".   I solve the problem the best I can, knowing full well, someone else might do otherwise.   Java needs tools like Gaelyk.  I started my EasyGSP project to have a truly lightweight option for developing my web applications. I'm doing my apps with no container now.  The java community does not seem to be craving for this type of lightweightness.  Every app is not going to be the next facebook. Most apps are not going to be the next facebook.  My co-workers love Spring and every problem is a Spring problem.  They would never give Gaelyk or my project a try.   I bet python developers rarely say "the right tool for the job", and I never hear this from my .Net developers say this.  I think the "right tool for the job" is the right approach but I think most will better off going with what you know best.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.