Doc Hudson: I’ll put it simple: if you’re going hard enough left, you’ll find yourself turning right.
Lightning McQueen: Oh, right. That makes perfect sense. Turn right to go left. Yes, thank you! Or should I say No, thank you, because in Opposite World, maybe that really means thank you.
In the above exchange from the movie Cars, Doc Hudson is explaining to Lightning McQueen the effect that dirt track drivers call drifting. Drifting occurs when the rear wheels of the vehicle loose traction and slide around as the car goes around a curve. With Lightning’s experience on paved tracks he has no idea what Doc is talking about. The drifting technique is best demonstrated by Doc in the following clip:
I feel as though I talk frequently to Lightning McQueen when implementing software systems. When I talk about the need to develop written specifications I hear “we do not have time to develop specifications”, “we know what we are doing so there is no need”, or “our customers are on a tight budget so we cannot afford to write specifications”. My typical response is “how could you afford not to write specifications.” The implications of failing to write specifications is that you spend several times the original effort fixing problems. Just because you know what you are doing does not mean you are aligned with customer expectations.
Earlier in the movie McQueen learns the hard way that turning left around the dirt track leads to him skidding into the cacti as he attempts to race Doc. Being a young race car with more energy than practical experience on dirt he cannot understand what happens. Later in the movie he tries over and over to make the turn and fails; even after Doc tries to explain the concept.
I can see how that happens to someone implementing a system. They get a piece of advice that is so far removed from their frame of reference they are not able to process it. They have always thought the way to implement a system is to rush through the initial setup and then rework, rework, rework. They were the super-hero that used brute force and multiple tries to finally get it to work. Meanwhile the customer has a horrible experience suffering through multiple drawn-out failures causing them to inspect quality into the work product.
The written specification ensures that all parties agree to what will be delivered. Without it a decision made during the build that does not align with the customer’s expectations is the same as defect. Why not eliminate this ambiguity before starting development?
As with McQueen, the system implementer with a completely different frame of reference frequently is told about the right way to do something, but cannot imagine it to be true. Seeing may be the only way to make them a believer.
Where I work, custom developed interfaces delivered to customers gave me the feeling that we were sliding off the track only to be pulled out by Tow Mater over and over again so that we could start over.
I picked an upcoming project with a need for heavy integration and told the team of a new requirement for approved technical specifications for each integration point. I heard all the objections I identified above. After that I heard an extra special objection: “we copy similar integrations, so we are not able to explain exactly what happens.”
There were a couple of bad assumptions made in the specifications that caused issues in the written code. The good news is the customer had ownership in those assumptions because they signed off on the spec. We adjusted the spec and simply moved on with everyone agreeing that it was a change (not a defect). We brought that project to closure on time, much quicker than any other project with custom integration. At the end the customer told us that their experience on this project was far superior to the past experience.
The best part of this project was that the team bought into the methodology and has become advocates.
As with McQueen learning to drift, after some practice, development specifications are becoming the new “way things are done” and I am proud of the team for making this transformation.