- Topic 23: Design by Contract
- Topic 24: Dead Programs Tell No Lies
- Topic 25: Assertive Programming
- Topic 26: How to Balance Resources
- Topic 27: Don't Outrun Your Headlights
This chapter is from the book
This chapter is from the book
This chapter is from the book
Topic 27: Don’t Outrun Your Headlights
It’s tough to make predictions, especially about the future.
Lawrence "Yogi" Berra, after a Danish Proverb
It’s late at night, dark, pouring rain. The two-seater whips around the tight curves of the twisty little mountain roads, barely holding the corners. A hairpin comes up and the car misses it, crashing though the skimpy guardrail and soaring to a fiery crash in the valley below. State troopers arrive on the scene, and the senior officer sadly shakes their head. “Must have outrun their headlights.”
Had the speeding two-seater been going faster than the speed of light? No, that speed limit is firmly fixed. What the officer referred to was the driver’s ability to stop or steer in time in response to the headlight’s illumination.
Headlights have a certain limited range, known as the throw distance. Past that point, the light spread is too diffuse to be effective. In addition, headlights only project in a straight line, and won’t illuminate anything off-axis, such as curves, hills, or dips in the road. According to the National Highway Traffic Safety Administration, the average distance illuminated by low-beam headlights is about 160 feet. Unfortunately, stopping distance at 40mph is 189 feet, and at 70mph a whopping 464 feet.6 So indeed, it’s actually pretty easy to outrun your headlights.
In software development, our “headlights” are similarly limited. We can’t see too far ahead into the future, and the further off-axis you look, the darker it gets. So Pragmatic Programmers have a firm rule:
Always take small, deliberate steps, checking for feedback and adjusting before proceeding. Consider that the rate of feedback is your speed limit. You never take on a step or a task that’s “too big.”
What do we mean exactly by feedback? Anything that independently confirms or disproves your action. For example:
Results in a REPL provide feedback on your understanding of APIs and algorithms
Unit tests provide feedback on your last code change
User demo and conversation provide feedback on features and usability
What’s a task that’s too big? Any task that requires “fortune telling.” Just as the car headlights have limited throw, we can only see into the future perhaps one or two steps, maybe a few hours or days at most. Beyond that, you can quickly get past educated guess and into wild speculation. You might find yourself slipping into fortune telling when you have to:
Estimate completion dates months in the future
Plan a design for future maintenance or extendability
Guess user’s future needs
Guess future tech availability
But, we hear you cry, aren’t we supposed to design for future maintenance? Yes, but only to a point: only as far ahead as you can see. The more you have to predict what the future will look like, the more risk you incur that you’ll be wrong. Instead of wasting effort designing for an uncertain future, you can always fall back on designing your code to be replaceable. Make it easy to throw out your code and replace it with something better suited. Making code replaceable will also help with cohesion, coupling, and DRY, leading to a better design overall.
Even though you may feel confident of the future, there’s always the chance of a black swan around the corner.
Black Swans
In his book, The Black Swan: The Impact of the Highly Improbable [Tal10], Nassim Nicholas Taleb posits that all significant events in history have come from high-profile, hard-to-predict, and rare events that are beyond the realm of normal expectations. These outliers, while statistically rare, have disproportionate effects. In addition, our own cognitive biases tend to blind us to changes creeping up on the edges of our work (see Topic 4, Stone Soup and Boiled Frogs).
Around the time of the first edition of The Pragmatic Programmer, debate raged in computer magazines and online forums over the burning question: “Who would win the desktop GUI wars, Motif or OpenLook?”7 It was the wrong question. Odds are you’ve probably never heard of these technologies as neither “won” and the browser-centric web quickly dominated the landscape.
Much of the time, tomorrow looks a lot like today. But don’t count on it.
Related Sections Include
Topic 12, Tracer Bullets
Topic 13, Prototypes and Post-it Notes
Topic 40, Refactoring
Topic 41, Test to Code
Topic 48, The Essence of Agility
Topic 50, Coconuts Don’t Cut It