Better: More Parallels between Medicine and Agile Software

I recently finished reading the book Better: A Surgeon's Notes on Performance by Atul Gawande. Having read The Checklist Manifesto: How to Get Things Right  (which I commented on earlier) I expected to learn not just about medical practice, but also about parallels between medicine and software development. Much of what Gawande says about performance in medical environments has can be said to apply to agile software teams, in particular, the need to focus on core practices, the value of retrospectives, and the value of generalists.

A discussion of how hand washing, a simple technique that is vital to infection control but that also requires culture change to implement with the discipline required to be effective, brought to mind how the challenges teams have being agile often center on the challenges of having teams begin to apply basic practices, without customization.

In the discussions of Polio vaccination and malpractice were excellent non-software examples of how we can benefit from retrospective practice, especially the prime directive, which reminds us that to improve we can't focus on blame, but rather on how decisions we made and how to make them better. A discussion of medical practice in war zones provided excellent anecdotes to relate when someone says that they can't gather data to measure performance and thus improve;  Gawande relates how combat doctors, those with the best excuses to not have time to do "paperwork" somehow find time to enter the data needed to track and improve the care of soldiers, while gathering data in hospitals seems to be hard.

In a profession where specialization is valued, Gawande discusses time spent in India, where understaffed hospitals mean that surgeons can't afford to specialize and yet get do well by collaboration, cross-training, and discussion; in short, how "generalizing specialists" help to eliminate roadblocks and help get the most value from a team.

Like all metaphors and comparisons, there are gaps. Doctors and Software Developers do different things, and work under different constraints. But by focusing on the differences you miss an opportunity to learn from those around you. This, to me, is the key lesson in Better.

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:

• To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
  -Dbuild.number=${bamboo.buildNumber} war
• To only change build artifacts and not any source files.
• To not misuse the app version, or change the names of any artifacts.
• To be simple and idiomatic.

I realized that that Grails itself changes the application metadata (application.properties) when it does a build. So I modeled this approach after code in one the gant scripts in the Grails distribution.
The steps are:

• Hook into a build event to add a property in to application.properties.
• Access the property using the gsp tag.
• Pass the value into the the grails war command using a Java property.

To create the event hook, create a file in your project/scripts directory called _Events.groovy that contains a method like:

eventCreateWarStart = { warName, stagingDir ->
    def buildNumber = System.getProperty("build.number", "CUSTOM")
    println("Setting BUILD_NUMBER to "\+ buildNumber)
    ant.propertyfile(
       file:"${stagingDir}/WEB-INF/classes/application.properties") {
         entry(key:"build.number", value:buildNumber)
   }
}

Then you can access the property with a GSP tag like this

<g:meta name="build.number">


And you can now display build numbers (or any other properties that you want to pass in from you CI system) in your Grails app. This worked for me with Grails 1.3.7. The only down sides are:

•  This works on a per-project basis (That is probably easily fixable)
• The properties that we set are hard coded. (this could be fixed with a convention  that iterates through all of the system properties that start with "build" for example).

I welcome any suggestions for improving this, or alerts that I'm using the entirely wrong idiom :)