I love my smart home. I also feel really fortunate to have it, especially given how my wife and I are complete opposites when it comes to technology. She admires the simple practicality of pen and paper, while the computer nerd in me always tries to squeeze out any efficiency in my everyday process (which is lived mostly on a computer screen).
It started with a light switch
When we moved into our new house last summer, I was able to convince her to buy some smart light switches so that we could turn off the light or control the fan in our bedroom at night without having to get out of bed or stumble back to the bed in the dark. Those few light switches quickly snowballed into a few more and a few more until now we have the opposite problem of never turning lights off manually and probably using more electricity than otherwise in the process!
But we continue to justify this smart home overhaul as an acceptable hobby. It’s a fun project for me to set up the smart routines or configure everything just so. And I’m always careful to install manual overrides for all our smart appliances, so we won’t be left in the dark when things inevitably break, and we find ourselves unable to control devices with our phones or voices.
Speaking of the dark
(You probably saw this part coming…) One morning, I woke up to a seemingly innocuous notification—my wifi network in my home had auto-updated. “This happens all the time, no big deal” I thought. But then I noticed my kitchen lights hadn’t turned on to greet me that morning. And several of my smart devices were coming in as “unresponsive” in my Home app. My smart home was collapsing! It took me several weeks before I had the time to really dig into the troubleshooting phase and finally fix the problem. But along the way I did more damage to my smart home than was necessary and reset things such that they may never be the same again.
“Smart enough” devices
In contrast to my smart devices, I also installed a few “kinda smart” devices that don’t connect to my Wi-Fi at all. Just simple motion-activated lights in some closets to replace the old pull-chain fixtures. Again, these may be an unnecessary indulgence, but still solve the problem of forgetting to turn off the light when leaving the closet or rummaging around in the dark just because you think you’ll be quick and you know where it is and you don’t want to have to remember to turn the light back off… But these new motion lights just work! They are smart in the sense that they are always on when you may need them but never when you don’t, yet they’re more reliable, cheaper, and easier to troubleshoot than my many other over-complicated smart home gadgets.
Over-engineered development
The fact that you can do just about anything with software is both its biggest asset and its biggest challenge. It gives us the potential to solve just about any problem, in nearly any way we can imagine. With enough time and resources, we can build essentially anything we can conceive of.
This is a huge risk because it means we have the potential to go down paths that aren’t even solving the right problem. When I started my smart home, I was trying to solve the problem of inconvenience—having to move from a comfortable spot to change the power state of the lights. That led to the deployment of a solution – the smart light switch! The temptation to take that solution and continue to apply it to every adjacent-seeming problem was high. We could have smart switches everywhere!
However, when I really considered the problem I was trying to solve with the closet light, I realized that it wasn’t exactly the same as the other lights. Here, I wanted something that would turn on when I was rummaging and off when the space was idle. While I could have programmed a smart switch and motion sensor combo to solve this problem, in fact, there was already a widely available, off-the-shelf solution that was less expensive to deploy and had much fewer dependencies to maintain over time for it to continue functioning.
“Smart enough” development
This got me thinking about design processes for technical solutions, and how we often end up with a simpler implementation than we imagined in the beginning. We should never discount the “simple solution” just because it doesn’t feel as robust. In fact, we often steer our clients toward simpler solutions, testing each assumption to suss out where complexity is really needed.
Everyone always wants the latest and greatest, shiniest new thing that has the potential to solve all their problems far into the future. But those solutions take longer to build, and therefore longer to have to deal with an old problem of something not working as efficiently as it should. Even then, when the over-complex solution is finally deployed, any change to its functionality that wasn’t deeply considered beforehand may take exponentially longer to implement due to fear of introducing regressions to the solution.
By getting clarity about the actual problem, we’re able to ask if a more simple solution would be “good enough,” or even better, at solving the problem. Sometimes the simple solution is much better in many ways, keeping your lights on only when light is needed.