20th October, 2022 Flying Cars
I remember “inventing” a flying car when I was frustrated with traffic as a little kid. I told my parents how cool it would be to just fly away from traffic jams, and I naively believed that a flying car would be the solution to traffic jams. When people set out to design software, they often find themselves in the same position as eight-year-old Floyd. They’re confronted with a problem and imagine some software that would solve that problem, just as I imagined my flying car solving my traffic woes.
As an adult, I can see how many new problems would get created by putting flying cars into the hands of everyday commuters: aircraft are immensely more difficult to pilot, traffic control in the sky is far more complicated and dangerous, personal aircraft for commuting would be tremendously expensive and wasteful, the consequences of accidents in the air are far more grave than those on the ground, and so on. This “invention” of mine wasn’t really worth building. My eight-year-old imagination wasn’t enough to bring something worthwhile into the world: it needed far more practicality and perspective.
The things that prevented my “invention” from being worthwhile are often the same things that plague software development -
- I didn’t truly understand the problem. Eight year old Floyd had no idea why traffic jams happened, what contributed to them, and what others had already tried to do to eliminate them.
- I didn’t understand the consequences. I could easily say “I want a flying car” and imagine myself (or my parents) piloting it and waving goodbye to traffic jams forever. But getting what I wanted (were it even possible) would have been dangerous, expensive, inefficient, and environmentally irresponsible.
- I didn’t see the big picture. I didn’t consider that every roadway becoming a take-off and landing zone for aircraft would be staggeringly unsafe. I didn’t know how much more a personal vertical take-off aircraft would cost over a typical Toyota sedan. I didn’t understand how much harder it is to fly an airplane than it is to drive a car.
When I reflect on the challenges of software product design throughout my career, I see many similarities to my failed flying car invention. Software as a creative medium is so malleable: it seems like imagination is the only bounding constraint. Alas, if only it were so. Here are some recommendations that may help you find grounding in the practical and feasible.
Take time to clearly understand the problem. Make sure everyone involved can see the breadth and depth of the problem that needs solving. Even if you are confident you know what the solution is, set that solution aside until you’re certain that the problem is well understood.
Remember the Pareto principle. A simple solution that solves 80% of the problem is usually worthwhile. The remaining 20% is usually much harder.
Remain open to alternative solutions. It’s rare that the first idea is the best one.
Start small and evolve. Don’t wait too long or build too much before trying it out in the real world. See if it works well or not, and then use what you learn to shape how you continue to grow (or prune) your solution.
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
— Antoine de Saint-Exupéry