[dstroot]

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was.

If I engineer a bridge I know the load the bridge is designed to carry. Then I add a factor of safety. When I build a website can anyone on the product side actually predict traffic?

When building a bridge I can consult a book of materials and understand how much a material deforms under load, what is breaking point is, it’s expected lifespan, etc. Does this exist for servers, web frameworks, network load balancers, etc.?

I actually believe that software “could” be an engineering discipline but we have a long way to go

[parliament32]

> can anyone on the product side actually predict traffic

Hypothetically, could you not? If you engineer a bridge you have no idea what kind of traffic it'll see. But you know the maximum allowable weight for a truck of X length is Y tons and factoring in your span you have a good idea of what the max load will be. And if the numbers don't line up, you add in load limits or whatever else to make them match. Your bridge might end up processing 1 truck per hour but that's ultimately irrelevant compared to max throughput/load.

Likewise, systems in regulated industries have strict controls for how many concurrent connections they're allowed to handle[1], enforced with edge network systems, and are expected to do load testing up to these numbers to ensure the service can handle the traffic. There are entire products built around this concept[2]. You could absolutely do this, you just choose not to.

[1] See NIST 800-53 control SC-7 (3)

[2] https://learn.microsoft.com/en-us/azure/app-testing/load-tes...

[wat10000]

I think it is in certain very limited circumstances. The Space Shuttle's software seems like it was actually engineered. More generally, there are systems where all the inputs and outputs are well understood along with the entire state space of the software. Redundancy can be achieved by running different software on different computers such that any one is capable of keeping essential functions running on its own. Often there are rigorous requirements around test coverage and formal verification.

This is tremendously expensive (writing two or more independent copies of the core functionality!) and rapidly becomes intractable if the interaction with the world is not pretty strictly limited. It's rarely worth it, so the vast majority of software isn't what I'd call engineered.

[beachy]

Software and bridges are entirely different.

If I need a bridge, and there's a perfectly beautiful bridge one town over that spans the same distance - that's useless to me. Because I need my own bridge. Bridges are partly a design problem but mainly a build problem.

In software, if I find a library that does exactly what I need, then my task is done. I just use that library. Software is purely a design problem.

With agentic coding, we're about to enter a new phase of plenty. If everyone is now a 10x developer then there's going to be more software written in the next few years than in the last few decades.

That massive flurry of creativity will move the industry even further from the calm, rational, constrained world of engineering disciplines.

[avianlyric]

> Bridges are partly a design problem but mainly a build problem.

I think this vastly underestimates how much of the build problem is actually a design problem.

If you want to build a bridge, the fact one already exists nearby covering a similar span is almost meaningless. Engineering is about designing things while using the minimal amount of raw resources possible (because cost of design is lower than the cost of materials). Which means that bridge in the other town is designed only within its local context. What are the properties of the ground it's built on? What local building materials exist? Where local can be as small as only a few miles, because moving vast quantities of material of long distances is really expensive. What specific traffic patterns and loadings it is built for? What time and access constraints existed when it was built?

If you just copied the design of a bridge from a different town, even one only a few miles up the road, you would more than likely end up with a design that either won't stand up in your local context, or simply can't be built. Maybe the other town had plenty of space next to the location of the bridge, making it trivial to bring in heavy equipment and use cranes to move huge pre-fabbed blocks of concrete, but your town doesn't. Or maybe the local ground conditions aren't as stable, and the other towns design has the wrong type of foundation resulting in your new bridge collapsing after a few years.

Engineering in other disciplines don't have the luxury of building for a very uniform, tightly controlled target environment where it's safe to make assumptions that common building blocks will "just work" without issue. As a result engineering is entirely a design problem, i.e. how do you design something that can actually be built? The building part is easy, there's a reason construction contractors get paid comparatively little compared to the engineers and architects that design what they're building.

[mckn1ght]

Software packages are more complicated than you make them out to be. Off the top of my head:

- license restrictions, relicensing

- patches, especially to fix CVEs, that break assumptions you made in your consumption of the package

- supply chain attacks

- sunsetting

There’s no real “set it and forget it” with software reuse. For that matter, there’s no “set it and forget it” in civil engineering either, it also requires monitoring and maintenance.

[VorpalWay]

I have talked to colleagues who wrote software running on microcontrollers a decade ago, that software still runs fine. So yes there is set and forget software. And it is all around us, mostly in microcontrollers. But microcontrollers far outnumber classical computers (trivially: each classical computer or phone contain many microcontrollers such as SSD controllers, power management, wifi, ethernet, cellular,... And then you can add appliances, cars etc to that).

If something in software works and isn't internet connected it really is set and forget. And far too many things are being connected needlessly these days. I don't need or want an online washing machine or car.

[sarchertech]

Ignoring the actual useful reasons to connect something to be internet, the subscription business model is just too damn tempting.

[mckn1ght]

True, using a library in a cheap coffee maker you can maybe set it and forget it. I have an old TI-85 calculator that’s never needed to update its OS, while Apple has obsoleted multiple generations of applications in its never ending upgrade cycle.

But for mission critical applications the bar is a little higher. Isn’t this why we have the ongoing dialogue about OTA updates for Teslas etc and the pros and cons of that approach? Because if you can’t OTA patch a bug, you have to issue a recall [0]. But if you have internet connectivity, as you rightly point out, then you have a whole new attack surface to consider.

I just don’t think it’s all that simple.

[0]: https://www.cbsnews.com/amp/news/ford-recall-lincoln-explore...

[VorpalWay]

Indeed it isn't easy, but for car software, why couldn't you do the software upgrade offline, while at the mechanic, or via a USB drive with a signed installer, or via a phone app plugged into a USB port in the car? For a basic car there really isn't a need to be always online.

My car just has a bluetooth stereo, and it isn't very old. Yeah it is a basic model, but I really don't need or want connectivity in it. The one argument I could see would be showing maps, but I need offline maps anyways since I often lack any sort of mobile phone connection where I'm going. And you can update maps on a monthly basis (mobile phone app over USB while parked at home would work perfectly for this). Currently I just run OsmAnd on my phone with openstreetmap data downloaded in advance. Realtime traffic information perhaps could be an argument, but again, better to distribute that via FM radio that has better coverage (or even AM radio in some parts of US as I understand it).

And cars might be the odd one out. There really is no excuse for exposing washing machines and other applicances online. Especially since they are likely to last for a lot longer than the software will be supported. The fridge and freezer at my parents is around 20 years at this point for example. My washing machine is over 10 and going strong. I doubt they would get software security support for that long.

[radiorental]

>I actually believe that software “could” be an engineering discipline but we have a long way to go

It certain mission critical applications, it is treated as engineering. One example - https://en.wikipedia.org/wiki/DO-178B

[jr3592]

There are also fundamentally different acceptance criteria for a bridge vs a website. Failure modes differ. Consequences of failure are nowhere near the same, so risk tolerance is adjusted accordingly. Perhaps true "engineering" really boils down to risk management... is what you're building so potentially destructive that it requires extremely careful thought and risk management? Engineering. If what you're building can fail, and really cause no harm, that's just building.

[dml2135]

What you are describing sounds like a specific subset of professional engineering discipline, but I'd argue that "engineering" is much larger -- it isn't only "engineering" when you do it well and responsibly, after all.

I'd propose a definition of engineering that's more or less just "composing tools together to solve problems".

[rdiddly]

The way the authors of the book on material strengths got those numbers, was through testing. If you're using mature technologies, that testing has been done by others and you can rely on it for your design, at least in a general way. Otherwise you have to do the testing yourself, which is something a structural engineering project might do also, if it's unusual in some way.

[jimbokun]

We have a long way to go but large software companies have gotten really, really good at scaling to handle larger and larger traffic loads. It's not like there are no materials to consult to learn current best practices, even if there are still more improvements to be made.