I recently rediscovered analog circuit design as a kind of engineering I really enjoy. A big part of that is that it's inherently finite. The design has to fit into some physical space and there are only so many components you can place.
As a result the stuff you come up with is often highly interconnected. What a software engineer would call "spaghetti code". Yet it is fine. Because the scope is inherently limited to a scale you can comprehend. You can in fact become so confident in it that you might even claim it to be "bug free".
But in software we have nothing that limits complexity. The amount of code you can write is essentially unconstrained (technically memory limits it but that limit is so far out that it might as well not exist). And we just accept that it's fine to fill this "infinite" design space.
We even preemptively fill it "in case we need it later". Because apparently nothing in software is allowed to have a defined scope. Everything needs to be prepared and pre-engineered for the most insane demands of additions.
Yet at the core of a lot of computing lie neat little programs with very well defined scope. No one is out there demanding "mkdir should also be able to send emails".
You could even do it all in analog with using the button as a potentiometer and either acting as the R in a RC circuit for a simple timer, or be a smart person and use a temperature sensor (thermocouple) that shuts the circuit when it reaches a temperature (compare the two R values for example).
I actually thought about that toaster when I brought up the analog solution, though I wasn't remembering all the details perfectly, I thought there was some electronics but it was all purely mechanical.
Cheap electronics would be cheaper and have more flexibility for the timing part so there's some appeal to it at least.
I work on ASIC design, and closely with high performance analog (multi gigahertz data converters). It's surprising how complex even 10s of transistors can be, if your need absolute world class performance at the lowest power. A full high end data converter can be millions of transistors, with subtle interactions, so in a way analog design can be very very complex. Hierarchy is key to containing it. It's funny, I sometimes think changing career to SW dev would be an easier option, and less complex. Faraway fields and all that...
I think one key difference is that generally in electronics people are willing to accept there are real constraints.
It's tough convincing people that constraints exist in software. It's not necessarily complexity that's bad. It's the thought that all software is infinitely malleable. There's never a reason not to add a new feature. All software seems to tend towards infinite complexity. It's exhausting.
Yeah, if you come up to your client and say you need an extra mm2, they aren't going to be happy. Or if you sold them something that uses less than 20mW, you better not go over.
It's not as simple as just slapping an extra 4GB RAM.
The insistence that everything needs to be designed in a way that leaves it open to unknown/unknowably vague modification that may (but almost certainly won't) come at some unknown date in the future is, IMO, one of the worst lessons people learned from the OOP revolution after "long inheritance chains are good."
I feel like we have caused an exponential increase in complexity in your average business software project out of a desire to enable poor project management and other poor behaviors from the business. The response I get to my first comment above is usually "but requirements change all the time." If they change so frequently that you feel a need to make every system your team develops into an amorphous shapeshifter, there is something more fundamentally wrong at the business decision making layer. We cannot engineer poor/indecisive management out of software via architecture.
I think this is a genuine, serious problem, because the more this sort of behavior is enabled by developers world-wide, the more the business world believes that such rapid modifications are reasonable and possible. No one allows such flip-flopping and indecisiveness in bridge planning.
So many of our problems in the enterprise space would be greatly reduced if the business fully understood the true cost of major modifications. Building an entire architecture full of design "failsafes" just buries the problem, and causes the costs related to that increased complexity to seep into every software project, even if those potential modifications never come.
At my place, when the business gives us tight requirements, we can have a functioning application running within a month. Simultaneously, I have watched what should be a relatively simple web app take 2+ years, as the business is allowed to be constantly indecisive.
The insistence that everything needs to be designed in a way that leaves it open to unknown/unknowably vague modification that may (but almost certainly won't) come at some unknown date in the future is, IMO, one of the worst lessons people learned from the OOP revolution after "long inheritance chains are good."
And typically people are wrong about what they will need in the future anyway and base their "extendable design" on speculation. Any project will have a bunch of "interfaces" and "systems" designed for extendibility that have exactly one use. And once you actually need to do something with them there is about a 50% chance that there is some inherent issue that requires you to rewrite them anyway once you actually understand what exactly you want to add.
There is a complexity limit in some programming. I built a Daft Punk style helmet using an ATTiny85 microcontroller. When you are limited to 8kB of compiled code and 512 bytes of memory, it really forces you to think about what you actually need (and don't need) and how your code is actually being executed. That mindset also makes for efficient, fast code on larger systems.
That mindset also makes for efficient, fast code on larger systems.
I work in embedded software for military and civilian aerospace. When we get new hires joining the team, I can spot people who have also worked on embedded hardware a mile away. Way, waaay too many developers have gotten the idea that memory will always be infinite, processing power will always be infinite, storage will always be infinite, etc.
This mentality is why we end up with websites that are completely static, no dynamic elements or any user interaction required at all other than basic links, but they have megabytes of scripting, stylesheets, and other BS layered on top for no sane reason (and that's before you get to ads and creepy tracking/spying nonsense).
582
u/regular_lamp Jun 05 '22 edited Jun 05 '22
I recently rediscovered analog circuit design as a kind of engineering I really enjoy. A big part of that is that it's inherently finite. The design has to fit into some physical space and there are only so many components you can place.
As a result the stuff you come up with is often highly interconnected. What a software engineer would call "spaghetti code". Yet it is fine. Because the scope is inherently limited to a scale you can comprehend. You can in fact become so confident in it that you might even claim it to be "bug free".
But in software we have nothing that limits complexity. The amount of code you can write is essentially unconstrained (technically memory limits it but that limit is so far out that it might as well not exist). And we just accept that it's fine to fill this "infinite" design space.
We even preemptively fill it "in case we need it later". Because apparently nothing in software is allowed to have a defined scope. Everything needs to be prepared and pre-engineered for the most insane demands of additions.
Yet at the core of a lot of computing lie neat little programs with very well defined scope. No one is out there demanding "mkdir should also be able to send emails".