Being Agile Means Understanding When to Change
Date Published: 12 December 2007
While I was completing my drive into work this morning, I was thinking about a book I read recently, Cryptonomicon (highly recommended – very smart and interesting), in which there’s an exchange between a WWII German cryptanalyst and some of his Allied counterparts. The German had discovered a flaw in the Enigma system used by the Germans during the war, and had written a paper about how to exploit the flaw (something the Allies had been actively doing, unbeknownst to Berlin, for some time). The Allies asked “But they’ve continued using the Enigma, despite your discovery!” to which the German replied “What? They’re supposed to throw away thousands of Enigma machines and come up with another solution because one man writes a paper?”
Does this ever happen in your organization? I know it’s a hard pill to swallow at times for me with my own company. A ton of work has gone into going down a particular path, and suddenly one little thing changes that makes that the wrong path. It takes a lot of will to decide that a change is required, and that decision can be made much easier if the software changes necessary to enact the change can be done with some degree of confidence that the end result will still work, and won’t be crippled by regression errors (or require months of effort and rewriting). Using agile methods, unit testing, continuous integration, etc. can make it so that, when tough decisions need to made about design changes or the direction a project is heading, the code can easily change to conform to the decision.
Another example (also a WWII reference) of this same concept I can recall from the much older book, A Bridge Too Far, which covers operation Market Garden (the largest parachute drop in history). In the planning stages of Market Garden, in England, one of the intel officers discovered what appeared to be tanks in the treeline in the town of Arnhem in two aerial photographs. The response to this new intel? “You expect us to stop this operation because of 2 photos that show tanks in Arnhem? We have hundreds of photos that don’t have tanks in them!” And the rest is history.
Steve is an experienced software architect and trainer, focusing on code quality and Domain-Driven Design with .NET.