Regarding "engineering is consequential" I think the Therac-25 incident is a far superior example of software having life-altering consequences. It is also worth noting that nobody uses or used waterfall. I recommend reading some of Barry Boehm's papers since he was one of the OG software engineers who worked on some of the first DOD software projects before I was born. We SEs always used iterative development, even if they didn't play buzzword bingo with words like "sprint" or "velocity" back in the 1960s. In fact if you look back at the literature such as in IEEE or ACM research papers, the term "waterfall" doesn't even show up until the 1990s right about the time the Agile Manifesto was written and Scrum and XP were becoming popular. I wrote a paper on this specific topic for my M.S. in C.S. a few years ago and I heavily cited Boehm's academic research because he wrote, and published, about these topics heavily in the second half of the 20th century. We always hear the boogeyman of "our profession used waterfall back before Agile and it was horrible" but nobody I ask can ever cite a specific example of this. I'm not trying to nitpick but this myth is like a vampire that refuses to die.
In fact, it's even worse than that. Waterfall was invented in a methodologies paper that set it up as an imaginary strawman of the worst possible way to run a project, as a baseline to compare everything else against.
Engineering is not about "physical" or "being licensed" as stated in this presentation. It is about being able to analytically engage with your system and its constraints (and those that they interact with) to make educated calls for managing risks and meeting requirements.--Mechanical Engineer
Very interesting talk. I would be interested in knowing if and how other engineering fields manage client expectations in terms of time and features and make them respect their knowledge amd experience.
Personally, I want to enforce licensing in some computing fields (I am a cyber security person), but it is unclear if the *engineering* idea makes sense. I have been studying (loosely) other analogies - clinicians and most notably chemists. In Quebec, some chemists are licensed, some not (where as all the clinical disciplines - medicine, nursing, clinical psychology, pharmacy, etc. are). My father was in the field and as a PhD-trained chemist the American pharmaceutical company he worked for for most of his career required licensing because the expectation was that a doctoral level worker would be responsible for aspects related to safety and such matters.
So I've been coding in some form for 40 years. I think what software engineering requires is some form of liability for people acting as software engineers. There's a place for a subset of it systems where the people and organisations building them have a legal and ethical liability. This is different from software crafting, where it is glorified playing and learning.
@@georgerogers1166 I would argue that it isn't the problem space, but the implications of the usage. If, for example, I wrote code to handle financial transactions where people may go to prison if bugs make it appear that they have committed fraud, then I should have been developing and maintaining that software under some professional or regulatory liability, with clearly set out obligations and duties. It isn't enough to say it's just software.
9:42 actually if the laser pointer is badly engineered you can go blind from it, so its not that low stakes. there are cases of people buying cheap lasers and instead of getting crappy 200mW ones, got 2W lasers that could do serious eye damage.
for me engineers create stuff by wrangling with real world physics. Programmers do not necessarily do that, rather they often create their own worlds with destinct physics. every code is its own universe.
Precisely : Math, CompScie and SoftEng are theory = create your own worlds. Physics, ChemEng, ElecEng, MechEng, AeroEng etc. are stuff in this world = make stuff that must conform to real physical laws. You can’t invent your own and make your “own” theory.
How are networks and computational limits not real world? Swe's have to understand how channeling data has very real physical limitations. Their solutions have to be able to scale with these limitations in mind. We also have to consider the feasibility of the consumption that computing may take (things like block chain and LLMs require tons of compute, is it realistically scalable over time? If not that's the upper bound on progress on those fields)
@@pedrov8868 even in your examples no coder has to know what voltage the cpu and memory need. no coder needs to know the amount of resistors placed inside the machine. and modern languages even abstract memory addresses away. Even the limitation you are citing are often dealt with by the operating system. programs work by switching logic gates - I have never seen the notion of such in higher level languages.
@@manuelmeyer1026 you said every code has its own universe but that is simply not true. Again, we can go with examples, a computer vision engineer has to understand image processing, basic physics of lights, etc, to be able to work best in their domain space. They cannot make their own universe on a whim. Maybe what you said is true for a subset of software engineers but not another.
And if this website leaks personal data (such as payment credentials) and it'll result in lives ruined - then maybe yes? And maybe even that PHP monkey should have been regulated and held accountable, like all proper engineers?
Regarding "engineering is consequential" I think the Therac-25 incident is a far superior example of software having life-altering consequences.
It is also worth noting that nobody uses or used waterfall. I recommend reading some of Barry Boehm's papers since he was one of the OG software engineers who worked on some of the first DOD software projects before I was born. We SEs always used iterative development, even if they didn't play buzzword bingo with words like "sprint" or "velocity" back in the 1960s. In fact if you look back at the literature such as in IEEE or ACM research papers, the term "waterfall" doesn't even show up until the 1990s right about the time the Agile Manifesto was written and Scrum and XP were becoming popular. I wrote a paper on this specific topic for my M.S. in C.S. a few years ago and I heavily cited Boehm's academic research because he wrote, and published, about these topics heavily in the second half of the 20th century.
We always hear the boogeyman of "our profession used waterfall back before Agile and it was horrible" but nobody I ask can ever cite a specific example of this.
I'm not trying to nitpick but this myth is like a vampire that refuses to die.
In fact, it's even worse than that. Waterfall was invented in a methodologies paper that set it up as an imaginary strawman of the worst possible way to run a project, as a baseline to compare everything else against.
Engineering is not about "physical" or "being licensed" as stated in this presentation. It is about being able to analytically engage with your system and its constraints (and those that they interact with) to make educated calls for managing risks and meeting requirements.--Mechanical Engineer
A sensible take!
Very interesting talk. I would be interested in knowing if and how other engineering fields manage client expectations in terms of time and features and make them respect their knowledge amd experience.
I can't tell if it's interesting or not, the quality of the audio is so bad.
Personally, I want to enforce licensing in some computing fields (I am a cyber security person), but it is unclear if the *engineering* idea makes sense. I have been studying (loosely) other analogies - clinicians and most notably chemists. In Quebec, some chemists are licensed, some not (where as all the clinical disciplines - medicine, nursing, clinical psychology, pharmacy, etc. are). My father was in the field and as a PhD-trained chemist the American pharmaceutical company he worked for for most of his career required licensing because the expectation was that a doctoral level worker would be responsible for aspects related to safety and such matters.
Today software engineering means using dependencies over dependencies. 😂
I've seen to many front end coders calling themselves Software Engineers 😂
Beautiful Talk 🍻👏🏻
Interesting topic only shadowed by the lack of good audio. The audio sucks. Maybe next time try to improve it.
The version control point is very real.
So I've been coding in some form for 40 years. I think what software engineering requires is some form of liability for people acting as software engineers. There's a place for a subset of it systems where the people and organisations building them have a legal and ethical liability. This is different from software crafting, where it is glorified playing and learning.
No. Depends on the problem space.
@@georgerogers1166 I would argue that it isn't the problem space, but the implications of the usage. If, for example, I wrote code to handle financial transactions where people may go to prison if bugs make it appear that they have committed fraud, then I should have been developing and maintaining that software under some professional or regulatory liability, with clearly set out obligations and duties. It isn't enough to say it's just software.
@@mrpocock exactly.
The people hiring should worry about that and hire accordingly.
9:42 actually if the laser pointer is badly engineered you can go blind from it, so its not that low stakes. there are cases of people buying cheap lasers and instead of getting crappy 200mW ones, got 2W lasers that could do serious eye damage.
for me engineers create stuff by wrangling with real world physics. Programmers do not necessarily do that, rather they often create their own worlds with destinct physics. every code is its own universe.
Precisely :
Math, CompScie and SoftEng are theory = create your own worlds.
Physics, ChemEng, ElecEng, MechEng, AeroEng etc. are stuff in this world = make stuff that must conform to real physical laws. You can’t invent your own and make your “own” theory.
How are networks and computational limits not real world? Swe's have to understand how channeling data has very real physical limitations. Their solutions have to be able to scale with these limitations in mind. We also have to consider the feasibility of the consumption that computing may take (things like block chain and LLMs require tons of compute, is it realistically scalable over time? If not that's the upper bound on progress on those fields)
@@pedrov8868 even in your examples no coder has to know what voltage the cpu and memory need. no coder needs to know the amount of resistors placed inside the machine. and modern languages even abstract memory addresses away. Even the limitation you are citing are often dealt with by the operating system. programs work by switching logic gates - I have never seen the notion of such in higher level languages.
@@manuelmeyer1026 you said every code has its own universe but that is simply not true. Again, we can go with examples, a computer vision engineer has to understand image processing, basic physics of lights, etc, to be able to work best in their domain space. They cannot make their own universe on a whim. Maybe what you said is true for a subset of software engineers but not another.
whatever. @@pedrov8868
"Is Audio Engineering Real Engineering?"... trying to listen to this talk, the answer seems to be "no!"
Just going to mention the Empire Theatre Move in New York, they moved the entire building.
👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻
"I havent been able to monetize my true passion, falling down rabittholes" - Hillel Wayne
Hi, in the thumbnail, what is the name of the book the person is hooding? Thank you.!
Hi, it's the 2nd edition of the "Handbook of Industrial Engineering" by Gavriel Salvendy: amzn.to/42ipA85
@@GOTO-
Thank you very much for this! Deeply appreciated.
If you're writing a website in PHP or Python or other similar things, I would say no. LOL -;)
And if this website leaks personal data (such as payment credentials) and it'll result in lives ruined - then maybe yes? And maybe even that PHP monkey should have been regulated and held accountable, like all proper engineers?
Please improve the sound next time!
I don’t care. Just let me code
No, it is not.
Yes, and who cares?