Over a million developers have joined DZone.

On Gaelyks and Golden Hammers

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}