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.