On Gaelyks and Golden Hammers

DZone 's Guide to

On Gaelyks and Golden Hammers

· Agile Zone ·
Free Resource
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.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}