Continuous Continuum

There are classics in technology literature, much like there is in any other category of writing.  Many classics are at least superficially dated and for more than a few, this runs deeper.  While this might be true for other forms, the rapid pace at which technology evolves means that a software engineering tome is much more susceptible to obsolescence than a novel concerning the folly of war.  And, of course, the pace at which something can attain "classic" status tends to be much quicker in the tech world as well.    I think there are at least a few books out there (and more every year) that I keep coming back to, and not just as a novelty (like when I pick up one of my original X Windows books from the 80s for a chuckle).    Fowler's  Refactoring, Brian Goetz's Concurrency in Java and Joshua Bloch's Effective Java are books that don't get old for me (and the later two are not great only within the context of the Java programming language).

Well, there's a new book in town.  Too early to tell if it'll take its place among those other tomes in my pantheon, but I have a feeling it'll make it to the second tier (along side such notables as Sam Ruby's RESTful Web Services, Kent Beck's Test Driven Development, Peter Coad's Java Design and Martin Ordesky's Programming in Scala).  The book?  Continuous Delivery by Jez Humble and David Farley.  It doesn't have anything ground breaking in it (technology books rarely do - the industry moves much too fast  while the publishing industry lumbers along much too slowly for that to happen).  But the subject itself is, to my mind, one of the most fundamental pieces of the IT pie, growing ever more fundamental as an organization grows.  It's also fundamental if utility computing is ever to approach its potential and become the underpinnings of a real enterprise level transformation (cloud everything hype aside).  

I've been consulting for the better part of 10 years now and have probably spent about half that time in trying to bridge the gulf between development and operations (and the other half helping to automate bits and pieces of the build/deploy/provision/configure puzzle or troubleshooting problems when some manual portion of that death march went haywire).    So it's a subject near and dear to my heart.  The book's well written and I'm liking it thus far (I just hope enough people who are not already members of the choir get their hands on this religion).    Let's pray that it does.