The job of engineers is not to deploy some technology but to build robust, reliable and sustainable (in all meanings of that word) solutions for real world problems based on requirements directly derived from people's needs.
-
@GerardThornley @tante All software ever written, unless its one of those special "formally verified" academic projects.
@alatiera @tante Then I think the phrase "don't have a single clue" might be putting it a little bit strongly!
For the software managing, for example, the timing of fuel injectors and spark plugs in all modern internal combustion engines, the engineers will have a very high (and justifiably high) level of confidence in how it will behave.
That's built on a great deal of work to measure things like the behaviour of raw materials (electronic components) including failure rates and conditions, model the behaviour of the system in a range of scenarios, and test the product at multiple stages during both design and manufacture.
All the same processes that give confidence in the construction of a bridge.In neither case will these efforts always manage to catch every single unintended outcome. A _fairly_ recent example would be the London millennium bridge, a footbridge over the Thames, which happened to have a resonant frequency at around people's walking pace, and had to have dampers added after construction to prevent an unpleasant rocking motion.
-
@tante The job of the engineer is to meet the specification. Period.
@Wyatt_H_Knott Yikes, when did you take Engineering Ethics? Never?
-
@Wyatt_H_Knott Yikes, when did you take Engineering Ethics? Never?
@phf Furthermore, anyone who thinks "Engineering Ethics" is a relevant class to actual engineering has done very little actual engineering.
In the second place, most things have very little ethical cachet.
In the FIRST place, you can, in reality, build whatever the fuck dangerous or harmful thing you can think of. (Especially if you're a CE.) And you really don't even have to put warning labels or guards on it, you can just deny that it's a danger. That's literally the legal precedent.
-
@alatiera @tante Then I think the phrase "don't have a single clue" might be putting it a little bit strongly!
For the software managing, for example, the timing of fuel injectors and spark plugs in all modern internal combustion engines, the engineers will have a very high (and justifiably high) level of confidence in how it will behave.
That's built on a great deal of work to measure things like the behaviour of raw materials (electronic components) including failure rates and conditions, model the behaviour of the system in a range of scenarios, and test the product at multiple stages during both design and manufacture.
All the same processes that give confidence in the construction of a bridge.In neither case will these efforts always manage to catch every single unintended outcome. A _fairly_ recent example would be the London millennium bridge, a footbridge over the Thames, which happened to have a resonant frequency at around people's walking pace, and had to have dampers added after construction to prevent an unpleasant rocking motion.
@GerardThornley @tante To this day they are rebooting f35 subsystems mid-flight when they bug out.
Not all software is trash-tier quality but we are nowhere close to the reliability and determinism you'd expect for any engineering field. And its not getting any better with all the deregulation and outsourcing to contractors.
-
@GerardThornley @tante To this day they are rebooting f35 subsystems mid-flight when they bug out.
Not all software is trash-tier quality but we are nowhere close to the reliability and determinism you'd expect for any engineering field. And its not getting any better with all the deregulation and outsourcing to contractors.
@alatiera @GerardThornley @tante this was preAI -- what will the future hold
-
@GerardThornley @tante All software ever written, unless its one of those special "formally verified" academic projects.
@alatiera @GerardThornley @tante
not just research prototypes. See the formally verified seL4 kernel:
Formal verification has come a long way
-
@tante Sun Tsu's "The Art of War", specifically the section on Tactics, is surprisingly relevant in Software Engineering. You have a powerful army. Don't ask it to do something it can't do
@CubeRootOfTrue @tante The job of an engineer is to say "no" and deliver.
-
The job of engineers is not to deploy some technology but to build robust, reliable and sustainable (in all meanings of that word) solutions for real world problems based on requirements directly derived from people's needs. Even for an engineer technology comes second at best.
“Overengineering is also bad engineering.” — one of my engineer grandfathers, contemplating a probable waste of materials
-
@ingram @Colman That was usually the point where I would walk down the hall, or to another department, and start digging through someone's private filing cabinet of legacy classified drawings.
Which is why we worked so hard to get production rates up - to be able to keep legacy engineers and historical build data in house and actually usable. Because all those files were worthless without the engineer who collected them and could give you the right set of notes without looking anything up.
@Wyatt_H_Knott @Colman That's great of those drawings are available. Not so good when it's your first time doing a maritime contact and are located a long way (>1000km) from any ships or ship designers.
The frustrating thing was the customer not seeing what the problem was with the spec their contractors had developed.
-
@alatiera @tante Then I think the phrase "don't have a single clue" might be putting it a little bit strongly!
For the software managing, for example, the timing of fuel injectors and spark plugs in all modern internal combustion engines, the engineers will have a very high (and justifiably high) level of confidence in how it will behave.
That's built on a great deal of work to measure things like the behaviour of raw materials (electronic components) including failure rates and conditions, model the behaviour of the system in a range of scenarios, and test the product at multiple stages during both design and manufacture.
All the same processes that give confidence in the construction of a bridge.In neither case will these efforts always manage to catch every single unintended outcome. A _fairly_ recent example would be the London millennium bridge, a footbridge over the Thames, which happened to have a resonant frequency at around people's walking pace, and had to have dampers added after construction to prevent an unpleasant rocking motion.
@GerardThornley @alatiera @tante
Back in the flash rom, coded in raw bits days, you could be reasonably certain engine controls would be deterministic and perform as intended (with some exceptions at edge / fault cases).
With today's complexity, excess interconnectedness, and code outsourced to lowest bidder; I would not be so sure.
I know of a tractor that reverse controlled fuel rate under certain input conditions. It would reduce power in response to throttle increase when parked with a PTO attached.
-
@GerardThornley @alatiera @tante
Back in the flash rom, coded in raw bits days, you could be reasonably certain engine controls would be deterministic and perform as intended (with some exceptions at edge / fault cases).
With today's complexity, excess interconnectedness, and code outsourced to lowest bidder; I would not be so sure.
I know of a tractor that reverse controlled fuel rate under certain input conditions. It would reduce power in response to throttle increase when parked with a PTO attached.
@johntimaeus @alatiera @tante
You could keep listing examples of bad engineering from the software world, and perhaps I could keep responding with examples from civil engineering.But this isn't a competition. The original comment was: "For all software ever written ... we don't have a single clue what will happen let alone how to reproduce issues."
The original comment was incorrect. The existence of someone just throwing a plank across a stream doesn't prove that no-one knows what's going to happen when a bridge is built, and the fact that poorly engineered software exists - and, yeah, there is a lot of it - doesn't prove that software can't be engineered.
-
@GerardThornley @tante To this day they are rebooting f35 subsystems mid-flight when they bug out.
Not all software is trash-tier quality but we are nowhere close to the reliability and determinism you'd expect for any engineering field. And its not getting any better with all the deregulation and outsourcing to contractors.
@alatiera @tante I suggest separating two concepts:
1. Whether software _can_ be engineered to create predictable systems. It can.
2. Whether systems _are_ being built with processes appropriate to the level of risk. According to your last comment this isn't happening. But it's nothing to do with the nature of software. -
@johntimaeus @alatiera @tante
You could keep listing examples of bad engineering from the software world, and perhaps I could keep responding with examples from civil engineering.But this isn't a competition. The original comment was: "For all software ever written ... we don't have a single clue what will happen let alone how to reproduce issues."
The original comment was incorrect. The existence of someone just throwing a plank across a stream doesn't prove that no-one knows what's going to happen when a bridge is built, and the fact that poorly engineered software exists - and, yeah, there is a lot of it - doesn't prove that software can't be engineered.
@GerardThornley @johntimaeus @tante You know that every piece of software written is more or less undefined behavior right?
Like 99.999999% of software is using a stack where its both impossible to not have undefined behavior and it relies on it to function.
-
@GerardThornley @johntimaeus @tante You know that every piece of software written is more or less undefined behavior right?
Like 99.999999% of software is using a stack where its both impossible to not have undefined behavior and it relies on it to function.
@GerardThornley @johntimaeus @tante Hell, it takes extreme effort to have deterministic floating point calculations. Like there are so many examples of insane things, you have to intentionally look away to think otherwise.
-
@tante In my experience, it's non-engineers who tend to focus on the tech and may need to be gently guided back to the problem they're trying to solve, from which a lot of engineers will look first for a simpler, less technical, or more general solution.
@GerardThornley @tante simplicity über alles
-
@Wyatt_H_Knott @Colman That's great of those drawings are available. Not so good when it's your first time doing a maritime contact and are located a long way (>1000km) from any ships or ship designers.
The frustrating thing was the customer not seeing what the problem was with the spec their contractors had developed.
-
@GerardThornley @johntimaeus @tante Hell, it takes extreme effort to have deterministic floating point calculations. Like there are so many examples of insane things, you have to intentionally look away to think otherwise.
@alatiera @johntimaeus @tante
Look, I'm not interested in debating a moving target.
You don't seem to know if your point is that software engineering is deregulated and outsourced, or that it's possible to create non-deterministic systems and therefore impossible to create deterministic ones.
I don't care. You made an incorrect claim. I corrected it. If someone else wants to continue this, they're welcome, but please do me the courtesy of dropping me from the mentions. I have better things to do. -
@alatiera @johntimaeus @tante
Look, I'm not interested in debating a moving target.
You don't seem to know if your point is that software engineering is deregulated and outsourced, or that it's possible to create non-deterministic systems and therefore impossible to create deterministic ones.
I don't care. You made an incorrect claim. I corrected it. If someone else wants to continue this, they're welcome, but please do me the courtesy of dropping me from the mentions. I have better things to do.@GerardThornley @johntimaeus @tante Both are my points you obnoxious debatelord. I don't care if its theoretically possible to write formally verified software when its done exactly nowhere and there are no regulations requiring it.
You clearly don't have anything better to do, otherwise you'd have a life instead of trying to well actually a 100 character post.
Go touch grass, if nothing else so you stop being a nuisance to those are you in the public.
-
@GerardThornley @tante To this day they are rebooting f35 subsystems mid-flight when they bug out.
Not all software is trash-tier quality but we are nowhere close to the reliability and determinism you'd expect for any engineering field. And its not getting any better with all the deregulation and outsourcing to contractors.
Canada needs S. Korea subs, with full tech xfer and Swedish planes with the same.
The USA ships late, over budget and expensive with vendor lock in.
Fuck that. We don't need the USA for hardware or software. Waste of money. -
@Wyatt_H_Knott @Colman That's great of those drawings are available. Not so good when it's your first time doing a maritime contact and are located a long way (>1000km) from any ships or ship designers.
The frustrating thing was the customer not seeing what the problem was with the spec their contractors had developed.
@ingram At that point you don't need the spec, you need the manual. The manual tells you what we did to meet the spec. Ideally. It certainly, in the Naval world, tells you what everything is and how to operate and maintain it.
