Bubble sort however, is always bubble sort. A similarly large portion of what engineers do with in software is constant

If Rome wrote an engineering manual, it would still be quite valid today.*

Considering many engineering standards from a few years ago are no longer valid, this is almost certainly not true.

We have some ancient engineering manuals. A book I read, most likely Brotherhood of Kings, remarked that Mesopotamian engineering manuals are primarily concerned with how many bricks will be required for a given structure.

The manuals are valid today, I guess, but useless. We prefer pipelines to brick aqueducts. Our fortresses are made of different materials and need to defend us from different things.

My program is more out of date (Java Server Pages, VHDL) but the school can't lower the quality of their programs. Generally, the standard learning requirements aren't on technology but principles, like learning OOP or whatever else. The CEAB audits student work from all schools in Canada to make sure it meets their requirements.

The culture itself is probably the most important part of the engineering major. They don't round up. If you fail, you fail. And I had a course in 3rd year with a 30% fail rate. Everything's mandatory, so you just have to try again over the summer.

A lot of people drop out because they can't handle the pressure. But the people that stay understand that they can't skip out on stuff they aren't good at.

I did not follow the path to become a licensed Professional Engineer, because a) there was no apparent benefit, b) to my knowledge, none of my colleauges were PEs and I don't know how I would get the necessary work certification.

Maybe there's corners of software where it's useful to become licensed, but not mine.

Standardization does not stop bad engineering. Those who think it does have not witnessed the catastrophe a bad standard can cause. Go download and implement the Microsoft Office OOXML standard - it’s freely available, ISO approved, 6000 pages, and an abomination that not even Google claims to have correctly implemented.

Where it’s bad is when the equipment to run that software no longer is manufactured. You can’t get a new computer to run Windows 95. Not even in the military. Your only option is to virtualize, adding a huge possible failure mode that was never considered previously.

Where it’s bad is when changes are needed to adapt to modern environments, and nobody’s quite sure about what they are doing anymore. There’s no test suite, never was, the documentation is full of ancient and confusing terminology, mistakes are made.

And on and on…

Most suspension bridges were built without a theoretical model, because didnt have one yet. Theory caught up much later.

Innovation often happens in absence of Theory.

That's not true, even for the first suspension bridge ever built (in the early 1800s), but it is true for example that many useful and impressive aircraft were built before the development of a physical theory of flight.

Your definition of theory only fits if you scope it so narrow that it's useless to the problem space.... Because the point is that theory didn't entirely cover that space. And bridges did collapse because of that.

But lack of theory didn't mean lack of rigorous testing. Gergie was built based on theory. Many other bridges were based on testresults..and did fine.

>Many other bridges were based on test results

I'm going to go out on a limb a little and assert that not a single bridge was built out of steel or iron in the last 200 years in the US or the UK without a static analysis of the compressive and tensile forces on all the members or (in the case of bridges with many hundreds of small members) at least the dozen largest members or assemblies.

It should be obvious that when you talk about theory covering a product, there either is a theoretical framework, or there isn't.

In the case of suspension bridges there wasn't. There was no mathematical theory to explain how the bridge stayed aloft, or how much it could carry.

What bridge builders of high quality did, was make mock (small) models. And test how much rocks they could put on them.

I think you will concede that that isn't a theoretical model. It's a practical one.

And this happens very often. People experiment and build useful things, but no one understands why they work. Until later people come along and explain the phenomenon.

If we (meaning software 'engineers' and I tepidly include myself in that group) had half the self control in introducing insanity like the 10000th new javascript framework to read and write to a database like the 'proper' disciplines do, maybe it would be better because there's less churn. Why does it have to move so fast? Software is diverse and inconsistent and rapidly changing because 'the industry' (coked-out developers chasing the next big hit to their resume to level up) says it should. I just don't agree that we need that amount of change to do things that amount to mutating some data. If the techniques didn't grow beyond what was cool in 2007, or they were held there until the next thing could be evaluated and trained, but the knowledge and process around them did, perhaps we'd be in a better position. I know I certainly wouldn't mind maintaining something that was created in the last decade of the previous millennium knowing it was built with some sort of self-control and discipline in mind, and that the people working on it with me had the same mindset as well.

Would a business get in trouble for using it? Sure. But if all the businesses in your country are at a competitive disadvantage because the competition is so much brighter elsewhere, and that “sloppy constructed” software is allowing international competition to have greater productivity and efficiency, your country is hosed. Under your own theory, imagine if the US was stuck with ~2007 technology while China was in 2024. The tradeoff would be horrific - like, Taiwan might not exist right now, horrific.

Regulating software right now would kill the US competitive advantage. It narrows every year - that would do it overnight. The US right now literally cannot afford to regulate software. The EU, which can afford it, is already watching talent leaving.

There’s also the problem of the hundreds of billions of lines of code written before regulations running in production at this very moment. There are not enough programmers on earth that could rewrite it all to spec, even if they had decades. Does Google just get a free grandfathered-in pass then, but startups don’t?

The fact that China is X number of years behind us, is easily demonstrable.

The amount of code running in the US, Y, is relatively easy to estimate by asking around.

Proving the amount of time it would take to modify Y lines of code to match any given law will exceed X number of years, thus putting us behind China, is also fairly easy to demonstrate, even if the exact amount of time is not.

Even our Apple II-era regulators know that going beyond that much effort (call it Z) is suicidal politically, economically, technologically, you name it. They might not understand tech, but they know it’s everywhere, and falling behind is not an option.

On that note, stop stereotyping our legislators. They have smartphones, younger aids, many of the oldest ones are retiring this cycle, etc.

“How to conduct water efficiently: first, collect a whole bunch of lead. Then construct pipes from said lead…”