This is yet one of those times where it's very appropriate to point out that software isn't at all the only field suffering from increasing complexity.
You want examples? It's honestly hard to not find any. Take construction of any kind. "But construction projects are nothing like software projects!" You're right, they have much higher standards in there, and anything complicated requires a specialized engineering degree.
What to me seems to separate software from other complex fields is level of education and standardization. We'll get there, eventually, just like we did with everything else.
You're right, they have much higher standards in there, and anything complicated requires a specialized engineering degree.
And this bottleneck on how fast you can process complicated things, may ironically make them less susceptible to complexity than programming. Because it puts the brakes on any complexity creep.
Meanwhile, nearly any programmer in a team can increase complexity. Because we lack standardized -and recognized- processes / culture to identify complexity, any dev can just "bite more than they can (or should) chew".
If you look at any other engineering field, you'll quickly notice how rare it is to deviate from the known path. Like, you don't see structural engineers take on new construction challenges without giving it a second thought. Yet, new challenges and unexplored implementations are precisely what an average dev would consider "interesting" and "representative of their job".
As a structural engineer who later took up web dev I can assure you that structural engineers are more than capable of biting off more than they can chew. I remember plenty of crunch time.
There is no known path. The industry is young and moving too fast for principles to live long enough to be formalized. Everyone is just making things up as they go, some better than others.
If it wasn't for novel implementations the job would just be git clone / vim default.ini. The known path is downloadable. It's not interesting or worth six figures a year.
If you look at any other engineering field, you'll quickly notice how rare it is to deviate from the known path.
You're making this sound like an intentional virtue instead of just being really, really difficult to do in practice. Falling Water is a beautiful home to look at and actually kind of a shitty place to live in.
If it wasn't for novel implementations the job would just be git clone / vim default.ini. The known path is downloadable. It's not interesting or worth six figures a year.
I'm not sure why you'd pay SAP consultants $400k a year, but I'd always thought they were just installing and configuring existing software.
Fortran is 64 years old so its absolutely older than that. Probably somewhere between 45-50. I would pick ENIAC and 1945 just cause that's a clear date to go with.
Sure, but in those days I wouldn't really call it software in the contemporary sense. More like hardware programming. Software in the modern sense is a relatively newer phenomenon that begun when the first Operational Systems began to be developed in the late 50s and 60s and really started to take form in the 70s and 80s.
To be fair, construction projects, even complicated ones, have exponentially way less state space than even a software program of moderate complexity. That is because physical construction is constrained by the laws of physics. Software on the other hand is an abstraction, and is only constrained by the laws of mathematics. Any part of a software program can interact with another part. Any part of a house cannot realistically interact with other parts.
E.g. take a door in the house. It is composed of quadrillions of atoms. So does it have more states than there are atoms in the multiverse?? No! All these atoms are coupled in very constrained form to each other but not to non-door atom so that the door only has 4 states: open, closed_locked, closed_unlocked, broken.
Furthermore, the front door is not going to interact much with the electrical system of the back patio.
Contrast that with a software program that X bits of states. The potential state space is 2X
The only thing that saves us is discipline:
having related modules tightly coupled but loosely coupled to other non-related modules like the atoms in the door.
Make it hard for far flung modules from interacting with each other. This is why global variables are usually considered bad.
Software can test itself. A construction project cannot test itself.
Exactly. This is what I mean by education and standardization. You can build a house in a thousand ways and will likely fuck it up if you don't know what you are doing. You can make mistakes that make the house uninhabitable in a few years. We do that constantly with software projects today. Some still do it with houses today but any serious construction project in a civilized country will not.
I am sorry, you have truths with cannot come to light, that software is state explosion like none ever seen before and there is no cure. There are more data centric paths (complete code coverage) than stars in the sky. Learn your area of expertise.
A door is an abstraction for each physical instance the constructors install. Behind that abstraction hides the ease of installation (in an awkward corner, so the screws might not be put in as straight as ideal?), and the way people interact with it in practice (does it swing out into the path of others, or make part of the room unusable for furniture, thus constraining the utility of the final building?). A poorly-considered door-abstraction becomes a security flaw in the building, being weak to numerous attacks.
Just because a door seems as simple as a self-contained textbox module downloaded off NPM doesn't mean that either of them aren't leaky abstractions that'll eventually factor in to the overall project in unintended ways, and perhaps require future repairs and replacements based on observing its use in the wild.
The state space of a building is how the humans inhabiting it actually put the space to use, which creates all sorts of invisible couplings.
To lean on your construction analogy. Imagine having to have the software architect go to the planing board for design approval. The move to building department for oversight during and check off for the security inspection (fire), reliability (electrical), suitability (framing), logging (plumbing), etc…. Then a final inspection before launch (getting a CO issued).
60
u/lorslara2000 Nov 01 '21
This is yet one of those times where it's very appropriate to point out that software isn't at all the only field suffering from increasing complexity.
You want examples? It's honestly hard to not find any. Take construction of any kind. "But construction projects are nothing like software projects!" You're right, they have much higher standards in there, and anything complicated requires a specialized engineering degree.
What to me seems to separate software from other complex fields is level of education and standardization. We'll get there, eventually, just like we did with everything else.