Knowing Where You’re Going
There was an article in last month’s IFR Magazine (the self-proclaimed “Magazine for the Accomplished Pilot”) entitled Skip Flight Planning. Flight planning has changed in recent years from being a tedious process concerning lines on maps, analogue computers (a.k.a. slide rules or E6Bs) and pages of arithmetic to become a tedious process of typing waypoints into a computer and allowing a site such as aeroplanner to do the hard work. The article in IFR took this one stage further: it’s unlikely that you’ll travel the route that you planned since a combination of Air-Traffic Control and the weather, two entities over which a pilot has little control, will reroute the flight anyway, so why do a lot of planning? We have more sophisticated devices in the aircraft now to allow us to replan our route and recalculate fuel burns while we’re en route so, apart from getting a good weather briefing on the ground, planning should be minimal.
This is, of course, reflected in the way that we schedule software projects. We used to spend a great deal of time up front (“on the ground”) putting very complex plans together, believing (or at least pretending that we were believing) that this time requirements wouldn’t change on us—that we would proceed effortlessly along the pre-ordained route with the pre-calculated fuel burn before arriving at our destination on time and on budget.
I am told (although I have never been able to find the source) that it was Einstein who said “Insanity is doing the same thing over and over and expecting a different result”. I have worked with software projects for 25 years and repeatedly witnessed the triumph of hope over experience—this next project will be different. Various forms of Agile Programming, up to and including eXtreme Programming have been proposed to reduce the amount of pre-work, accepting that it will probably change anyway, but can we really say that they have made a major impact on most companies’ thinking? I believe not.
Pilots didn’t relinquish their extensive pre-flight planning until genuine tools emerged that are fitted in the aircraft, that can give almost immediate updates on the implications of rerouting decisions and, most importantly, that are trustworthy. eXtreme Programming and its friends come with a process, a limited set of tools and no indication that what those tools say is trustworthy. Of course, some of the agile techniques (e.g., test-driven coding) have an almost immediate feedback but most cannot be understood by the people who make decisions. An airline executive can step into a cockpit where she understands little, but a moving map with terrain features, flight bars, fuel displays, etc. is immediately understandable. And when she sees that these tools allow her aircraft to recalculate routes dynamically and fly much more directly to their destination, thereby saving fuel, she is over the moon.
What is the equivalent device or tool in the eXtreme Programming world? What one thing convinces the executive with little software knowledge that leaving behind the enormous (and unproductive) up-front planning can lead to quicker and better results? Having given Agile Techniques briefing to executives, I don’t believe that it is there.