Not long after I joined Amazon, they sent an email to all engineers. The gist was simple: “We realized engineers sometimes make designs unnecessarily complicated because sophisticated designs can look better in performance reviews. We’re updating the engineering ladder to explicitly call out unnecessary complexity as a negative.”
Alas, this post is not about Amazon. This post is about my car’s occupancy sensor, and how it reminded me of good software design.
My car has different profiles for different drivers, and it can choose the correct profile based on the phone key used. Until recently, it was successfully connecting to my phone’s Bluetooth as soon as my profile was enabled. Out of nowhere, it suddenly stopped working. Everything else works fine, and I can manually click “connect to my phone”, but it just doesn’t connect automatically anymore.
Baffled, I started looking online. Turned out this was a common issue with Teslas and the culprit was the broken occupancy sensor. Apparently, my car has a sensor specifically for signaling if the seat is “occupied”. Since that sensor is now broken, the car thought there was no one “occupying” the seat, so it obviously didn’t try to connect to “no one’s phone”.
Interesting thing is, the car still picks the correct profile, lets me drive, and alerts if I don’t buckle up - the car clearly has enough information to know I’m driving. Now, I’m neither an automotive nor a safety engineer, but it feels to me this is an unnecessary dependency. By making Bluetooth depend on one more component, they introduced another failure mode into a feature that seemingly didn’t need it.
How does this connect to software systems? Well, exactly the same way. Whenever you’re adding a new dependency or coupling in your system, ask yourself if it’s truly necessary. See if you can achieve your goal with fewer components and/or dependencies. Keep your systems simple.
Sometimes that dependency is unavoidable. Bluetooth shouldn’t connect to my phone just because I happen to walk past the car. But if the car already knows that my key unlocked it, my profile is active, and I’m driving it, what additional information is the occupancy sensor providing?
Maybe there’s a good answer; I don’t know Tesla’s constraints. But it’s exactly the question we should be asking when designing software.
Every dependency you add creates another assumption your system makes about the world. This service will be available. This data will exist. This sensor will work. And every assumption is another way your system can fail.
Don’t ask only whether adding something makes the system better. Ask whether the system can work without it.
Because perfection isn’t when there’s nothing left to add. It’s when there’s nothing left to remove.