> 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 5 hours ago | parent | next [-]

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

▲

beachy 5 hours ago | parent | prev | next [-]

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 3 hours ago | parent | next [-]

> 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 5 hours ago | parent | prev [-]

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 3 hours ago | parent [-]

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 2 hours ago \| parent [-]
		Ignoring the actual useful reasons to connect something to be internet, the subscription business model is just too damn tempting.

▲

radiorental 5 hours ago | parent | prev | next [-]

>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

▲

jimbokun 3 hours ago | parent | prev | next [-]

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.

▲

rdiddly 4 hours ago | parent | prev | next [-]

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.

▲

jr3592 4 hours ago | parent | prev | next [-]

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.

▲

wat10000 5 hours ago | parent | prev [-]

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.