Driving a Car, Not Aiming a Bullet — the Driving Analogy
As I work on Implementing Agile Values and Principles, the follow-up book to Understanding Agile Values and Principles (UAVP) (https://www.infoq.com/minibooks/agile-values-principles/), I have been editing out material that, while of some interest, does not really advance the point of this new book. I’ve decided to post this material, bit by bit, here on Medium. This is the fourth of these.
— — — — — — — — — — — — — — — — — — — — — —
Comparing software development to driving a car is an analogy (by, I believe, Kent Beck) that I encountered early in my pursuit of Agile methods. I have found it a useful analogy over the years for discussing what methods should be intended to do and how they should be viewed.
Think of methodologies as “the line down the middle of the road.” You can cross that line and drive on the other side of the road almost without consequence if you can see far enough down the road. And, even if you cannot, crossing the line doesn’t mean instantaneous disaster. However, where the line is a dash, suggesting you can cross over, that doesn’t guarantee that you can or should. So, the “line down the middle of the road” is simply guidance or a warning that risk exists and consideration needs to be given to what that risk means. Of course, there are other indicators along the road (e.g., signs and traffic lights) offering further guidance. And, staying on your side of the line does not guarantee safety, either. There is always the person coming the other way who crosses the line against the guidance. Also, most potholes do not come with warning signs.
Driving is, in some ways, a useful model for software development. Even when we have driven the same way to work at the same time day after day, the traffic itself is not necessarily the same. There may also be detours because of construction or accidents. Yet millions of people manage to get to work each day, even if they change course, by knowing the guidance and assuming others do as well. Those who drive by ignoring, or being ignorant of, the guidance are dangerous.
The question is, do we respond to the fact that dangers exist by restricting and controlling driving like the old auto ride at Disney parks where movement is controlled by concrete barriers, governors on the engines, and extensive shock absorption bumpers around the entire vehicle? Some might say we should (especially that latter point), but we have structured our driving “methodology” assuming it is intended for those who know how to drive, as vague as that might be, and by penalizing and restricting individuals who indicate they do not know, rather than constraining the entire driving population.
Agile V&P are structured around a similar assumption of people “knowing how to drive” with specific practices being the instructions, at one level, for steering, applying the gas, signaling, etc. In the end, however, software development, like driving a car, is a somewhat repetitive, not totally predictable, and not absolutely controllable activity.
