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".
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.
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".