Hacker News Reader

Civil engineering doesn’t change. Gravity is a constant. Physics are constants.
Physics may be a constant, but materials and methods are not. There is a reason why ISO/IEC/ICC/ASTM/ANSI/ASME/ASHRAE/DIN/IEEE/etc standards have specific dates associated with them.

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.

That’s only a formality, but reality did not change, and neither did the fact that those standards would still work even if they would be slightly inferior.

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

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.

Physics will still be the same when your faulty software tells an airplane to dive.

In Canada, we have software and computer engineering programs accredited by the same entity (CEAB) that does civil engineering.

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've got an ABET accredited Computer Engineering degree from a US school. The only thing it got me in interviews was questions about why not CS.

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.

There is nothing saying that allowing for some standardization means that we have to be stuck at 2003-levels of state of the art. And actually, yes many engineering disciplines do change, Civil engineering brings in new construction techniques, methods for non-destructive testing, improvements to materials and on and on, but it doesn't do so like the coked-up industry of software does it in such a free-for-all manner. It's a proper engineering discipline because there's the control, testing the best way to do things and rolling that out.

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.

Simple - if you restrict the software industry, the US loses to China or any other country that doesn’t give a damn. And unless you censor the internet, there’s absolutely no way to prevent illicit software from crossing the border.

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?

I hope you realize that "sowwy, there's too much code :3" will not fly with whatever government decides to regulate software after the next major cock-up. We can either grow up and set our own terms, or we can have them forced on us by bureaucrats whose last computer was an Apple II. Choose.

Bull - regulators can’t change reality.

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.

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

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

Gravity is not constant, instead it varies by location and by height.

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

I'd imagine we wouldn't have ActiveX controls in the first place.

Wishful thinking - the IRS is still running on COBOL; our nuclear weapons until a few years ago on Windows 95. The NYC subway still has a lot of OS/2.

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.

You're making some points for me. You are assuming COBOL, Windows 95, or OS/2 are bad because they're old. Such assumptions are the antithesis of "engineering."

Old technology isn’t necessarily bad in itself. It’s well documented and understood.

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…

It sounds as if you're saying that these were bad things because they were always bad. And maybe they were. But we might never have any software at all if we only had good software.

I'm not saying they're bad because I don't know.

Apologies. I misread your intentions.

This is so wrong

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.

>Most suspension bridges were built without a theoretical model

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.

Galloping gertie is an example in America.

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.

You've retreated from, "built without a theoretical model, because didn't have one yet," way back to, "theory didn't entirely cover that space." This is commendable.

>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's disingenuous to read my comment as saying no theory existed, ever.

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.