the complexity tax
Two engineers, same problem, opposite exits. The middle ground between them is where most consumer tech lives and quietly fails.
Josh Sherman bought two smart bathroom scales. Both fought him over WiFi sync. Both got returned. The replacement was a plain electronic scale -- no app, no profiles, no subscriptions. Manual data entry. Done. His friend's line captures the whole thing: "If the device needs you, then it doesn't need to be smart."
Sumit Birla reached the same diagnosis and pulled in the opposite direction. His home automation philosophy: hardwire fixed devices, keep logic on the controller, no cloud dependencies, open standards only (MQTT, Modbus), no proprietary APIs. His pool pump runs off an industrial PLC with a Function Block Diagram that's legible to anyone who looks at it in 2030. He's not fleeing complexity -- he's demanding the kind that earns its keep.
Both moves are rational. Neither is the one the market wants to sell you.
what the middle costs
Consumer smart home products tried to bridge two worlds: the simplicity of a dumb appliance and the power of industrial automation. They borrowed the complexity without borrowing the discipline that makes industrial systems survive it.
A kitchen scale has no business with WiFi pairing, profile management, and a cloud sync queue. A thermostat has no business calling home to a server that might not exist in five years. These aren't engineering decisions -- they're product decisions dressed up as engineering. The complexity exists because a product manager thought it sounded like a feature, not because anyone ran the failure modes.
The result is a device that generates its own support burden. That's the tell. When a tool's complexity exceeds its competency to manage that complexity, you're paying a tax on every use: the flaky reconnect, the stale firmware warning, the app that needs an update before the scale will weigh you.
Birla's Rule #2 is blunter than it sounds: don't put high-level programming on low-level controllers. The corollary is that if you are going to run high-level logic, you'd better have the engineering rigor to back it. Consumer products almost never do.
the same tax in software
This isn't just a hardware problem. The pattern shows up everywhere complexity gets borrowed from serious systems and deployed without the operational discipline:
- CI configs that need their own CI to debug
- Frameworks that require third-party plugins to manage their own upgrade path
- Monitoring stacks that generate alerts about themselves
- Kubernetes clusters running two-container hobby projects
Each of these is a system that borrowed complexity from somewhere it was warranted -- large distributed infrastructure, enterprise deployments, serious scale -- and applied it somewhere it wasn't. The complexity doesn't disappear just because the scale shrank. It gets paid, one incident at a time, by whoever has to operate the thing.
The Arduino/Raspberry Pi comparison Birla makes is the same argument: those platforms are optimized for build velocity and discovery, not operational longevity. Code you write at 2am in 2020 is not legible to anyone, including you, in 2025. Industrial standards enforce a discipline the maker ecosystem doesn't have an equivalent for. That's not a knock on the ecosystem -- it's just a different optimization target. The mistake is deploying hobby-ecosystem tooling in infrastructure roles and being surprised when it behaves like a hobby project.
two valid exits
Sherman's exit is the underrated one. "Dumb enough to be robust" is not failure. It's a correct tradeoff. A scale that works every time, with no dependencies, is more valuable than a scale that works most of the time while demanding maintenance. The complexity got removed, not managed.
Birla's exit is expensive and requires genuine expertise. PLCs are not cheap. IEC 61131-3 is not beginner-friendly. But if you're building infrastructure you'll depend on for a decade, the investment in discipline pays off differently than it does for a consumer gadget. The artifact his approach produces -- that readable FBD diagram -- is legible to someone other than the original author. That legibility is the whole point.
The trap isn't complexity itself. It's complexity that doesn't come with the tools, standards, and culture to manage it. When you see a product that needed industrial-system complexity to pitch its features but shipped consumer-system engineering to build them, you're looking at a complexity tax you'll be paying every time something goes wrong.
Both exits beat staying in the middle. Pick the one that matches the stakes.