proverb driven development
Learning to drive at 17, my instructor had a bunch of proverbs or phrases that he used to describe different situations that you’d be in as a driver, and what your reaction to them should be.
- Keep it simple, keep it safe
- Only a fool breaks the 2 second rule
- When in doubt, don’t go out
- Less space less speed
- Gears to go, brakes to slow
All of them are applicable to software engineering. Lets break them down, one-by-one.
keep it simple, keep it safe
This is just a rewording of the famous KISS principle which is a design principle with origins in the US navy. KISS states the best systems are those that are simple, not complex. This is directly transferrable into software engineering. Where complexity must be removed so that enough of the systems can fit in engineers heads.
only a fool breaks the 2 second rule
For the driving instructor, this was about how close you were allowed to get to the vehicle in front.
Pick a spot, and when the vehicle in front gets there, start saying the proverb in your head. If your vehicle get’s to that spot before you finish the saying; then you are too close.
The really smart thing about this, is that because it’s time based, and there’s a triangle of distance/speed/time. Increasing speed, and keeping time constant means that distance must increase. In driving terms; if you are going faster, leave more space.
This too is true of engineering; the faster you go the more things can go wrong, and the more space you must leave for fixing defects / bugs, for correcting rushed decisions, etc. The faster you go the higher the chance of error, and the more space you must leave to counter that. It would indeed be foolish to rush ahead without considering the impact, and leaving yourself 2 seconds of space to work with.
The other interpretation of this is that the faster you go, the more time you mist leave for decisions. If you are going fast, make decisions slowly. Take 2 seconds to question if you are making the correct decision.
when in doubt, don’t go out
Don’t release code that you are not sure about. If you are in doubt don’t ship it. Find the information required to give you confidence, write the automated tests. If you do not understand a problem or the solution then it’s not really a solution. It may appear to work; but if you cannot reason about it then you cannot be sure that it fixes the issue. You are in doubt; do not ship it.
less space, less speed
If more “mission critical” a change is, the slower you must take it. Much like the “only a fool breaks the 2 second rule”, if the change you are making is to the most important part of the core of the product, or the change is irreversible you must slow down.
Anytime there’s less space for error, go more slowly to allow yourself the ability and the time to spot the errors. The bigger the “blast raduis” the slower you must go.
gears to go, brakes to slow
In the UK they used to teach learner drivers a skill of changing down through the gears, this used the weight and friction inside the engine to slow the car, instead of the brakes. It was used, in part, to increase the life of the brakes and brake pads, but could easily sacrifice the clutch.
Brake pads are a relatively cheap component in the car, the clutch is a more complex and more expensive one. This proverb is a combination of “use the right tool for the job” and protect your most expensive assets.
Using the right tool for the job might be a software tool, a programming language, a planning process, etc. But it’s also important to protect the expensive assets. This applies to data assets in terms of secutiry, to employess in terms of retention.
In the metaphor; protect the clutch (the part that links the power from the engine to the wheels that make things go!) and if you have to sacrifice something sacrifice the component that’s designed for that job, the cheap and disposable one.
I use mental models and proverbs like these to help make more informed and better decisions. And to help reason about situations and scenarions. The analogies are directory transferrable.