Are we really engineers?
January 26, 2021 2:14 AM Subscribe
Hillel decides to interview people, who switched from traditional engineering to software engineering. If you ever used the example of bridge building to explain the differences between software and real world engineering, you are in for a treat: One person talked about how frustrating it is to start work on a bridge foundation, only to find that this particular soil freezes in a weird way that makes it liquefy too much in an earthquake. Back to the drawing board. [Part I],
[Part II],
[Part III]
Great set of articles!
For me, I would add the distinction: why do you do it? If you are producing something for someone else to use (be it a bridge, a computer game, an Excel spreadsheet, or a car), that's a different style and standard to if you're just making something for yourself, even if you use the same skills and knowledge. Once you've crossed that threshold, you're engineering, it's just a question of how well you're doing it.
posted by Wrinkled Stumpskin at 6:04 AM on January 26, 2021
For me, I would add the distinction: why do you do it? If you are producing something for someone else to use (be it a bridge, a computer game, an Excel spreadsheet, or a car), that's a different style and standard to if you're just making something for yourself, even if you use the same skills and knowledge. Once you've crossed that threshold, you're engineering, it's just a question of how well you're doing it.
posted by Wrinkled Stumpskin at 6:04 AM on January 26, 2021
Pedantic but you're an engineer if you're an engineer, that said I've encountered 0 times in my life anyone requesting a CEng developer.
https://www.theiet.org/career/professional-registration/
https://www.bcs.org/get-qualified/become-chartered/chartered-engineer-ceng/
https://charteredengineer.nl/professional-registration/professional-titles/
posted by Damienmce at 6:23 AM on January 26, 2021 [2 favorites]
https://www.theiet.org/career/professional-registration/
https://www.bcs.org/get-qualified/become-chartered/chartered-engineer-ceng/
https://charteredengineer.nl/professional-registration/professional-titles/
posted by Damienmce at 6:23 AM on January 26, 2021 [2 favorites]
→
Oh please. Until you've seen transmittals management in a large construction project or redlining in a legal shop, your version control is a toy. Can you say (possibly under oath) that once you've made a revision and transmitted it, every user of your project is legally bound to have and use the new form of all the information? Can you do that to an office with no network connection, on paper, in the cold/mud/dust? In construction, if you don't, you'll get sued until all that's left of your huge company is a tiny smear of ink in a legal precedent.
Legal shops manage revisions in bloody Microsoft Word. You can't shy away from it saying you're a vi/emacs/whatever tiny grey text in a huge window editor you're into this week-text editor user. You get a Word doc, you use Word on it.
With software, you can try stuff, test it for failures and regression and integrate changes into a project quickly. In construction, you can't: "Hey, I'm just gonna take this backhoe and see if we can't find a better foundation site in the next lot over" said no construction engineer ever. Does software development have equivalents of finding a flowing artesian well (dig a hole, it starts to fill up with water basically forever), karst (a cavern under seemingly solid limestone corroded out by water flow: looks solid, isn't) or expensive archaeology that could move or cancel a project?
Game-changing innovations do exist in physical engineering. In the last 20 years, daylighters (hydrovac, hydro-excavators, potholers or vacuum trucks) have revolutionized construction. You can dig straight down, without having to allow for traditional excavator arm swing. They're gentle enough that you can uncover buried cables without damaging them. They're a huge safety gain over traditional excavation, too. They are noisy bastards, though, with all the site issues that brings. At least you can't hear all the precious clicky keyboards over them.
Software engineering's young. It'll take at least a couple more centuries to shake out the processes. It's still full of fads and prejudices. I mean, the only software that's proven itself able to keep running for decades, structured for readability like a contract, is basically a punchline: Cobol.
posted by scruss at 6:26 AM on January 26, 2021 [28 favorites]
Version control is the single most innovative, most revolutionary, most paradigm-shifting tool that is uniquely ours
Oh please. Until you've seen transmittals management in a large construction project or redlining in a legal shop, your version control is a toy. Can you say (possibly under oath) that once you've made a revision and transmitted it, every user of your project is legally bound to have and use the new form of all the information? Can you do that to an office with no network connection, on paper, in the cold/mud/dust? In construction, if you don't, you'll get sued until all that's left of your huge company is a tiny smear of ink in a legal precedent.
Legal shops manage revisions in bloody Microsoft Word. You can't shy away from it saying you're a vi/emacs/whatever tiny grey text in a huge window editor you're into this week-text editor user. You get a Word doc, you use Word on it.
With software, you can try stuff, test it for failures and regression and integrate changes into a project quickly. In construction, you can't: "Hey, I'm just gonna take this backhoe and see if we can't find a better foundation site in the next lot over" said no construction engineer ever. Does software development have equivalents of finding a flowing artesian well (dig a hole, it starts to fill up with water basically forever), karst (a cavern under seemingly solid limestone corroded out by water flow: looks solid, isn't) or expensive archaeology that could move or cancel a project?
Game-changing innovations do exist in physical engineering. In the last 20 years, daylighters (hydrovac, hydro-excavators, potholers or vacuum trucks) have revolutionized construction. You can dig straight down, without having to allow for traditional excavator arm swing. They're gentle enough that you can uncover buried cables without damaging them. They're a huge safety gain over traditional excavation, too. They are noisy bastards, though, with all the site issues that brings. At least you can't hear all the precious clicky keyboards over them.
Software engineering's young. It'll take at least a couple more centuries to shake out the processes. It's still full of fads and prejudices. I mean, the only software that's proven itself able to keep running for decades, structured for readability like a contract, is basically a punchline: Cobol.
posted by scruss at 6:26 AM on January 26, 2021 [28 favorites]
"Hey, I'm just gonna take this backhoe and see if we can't find a better foundation site in the next lot over" said no construction engineer ever.
Disruption opportunity detected: provide free backhoes and crowdsource foundation siting; pay bounties based on quality and size; monetize users once you have all of them.
posted by fatbird at 6:31 AM on January 26, 2021 [6 favorites]
Disruption opportunity detected: provide free backhoes and crowdsource foundation siting; pay bounties based on quality and size; monetize users once you have all of them.
posted by fatbird at 6:31 AM on January 26, 2021 [6 favorites]
I have a degree that says Software Engineering and my job title is Software Engineer but I still don't consider myself an engineer.
posted by octothorpe at 6:35 AM on January 26, 2021 [4 favorites]
posted by octothorpe at 6:35 AM on January 26, 2021 [4 favorites]
ISO 9001:2015, section 7.5.3.2
For the control of documented information, the organization shall address the following activities, as applicable:
a) distribution, access, retrieval and use;
b) storage and preservation, including preservation of legibility;
c) control of changes (e.g. version control);
d) retention and disposition.
[....]
Old versions of design drawings are kept; they just might have been in microfilm or hard copy. Nowadays of course we use computers and we do it all that way. But you can’t be ISO compliant without document control.
posted by Huffy Puffy at 6:51 AM on January 26, 2021 [2 favorites]
For the control of documented information, the organization shall address the following activities, as applicable:
a) distribution, access, retrieval and use;
b) storage and preservation, including preservation of legibility;
c) control of changes (e.g. version control);
d) retention and disposition.
[....]
Old versions of design drawings are kept; they just might have been in microfilm or hard copy. Nowadays of course we use computers and we do it all that way. But you can’t be ISO compliant without document control.
posted by Huffy Puffy at 6:51 AM on January 26, 2021 [2 favorites]
I recall a talk (from Ward Cunningham, maybe, but I can no longer find the link) that pointed out that engineers were building big arched bridges before we had calculus. They would build models of various sizes, break them, figure out the scaling laws, and then build the full-size bridge with confidence. I feel strongly that software engineers are engaging in at least this proto-engineering.
We don't have the analytical toolset to design software any other way, and we suffer in comparison to engineering disciplines that have worked hand-in-hand with mathematics and the physical sciences for centuries, but we are definitely doing what engineers did before they had the analytical tools necessary to do things differently.
(Disclosures: I have a PhD in computer science, am currently working as a software engineer, and come from a long line of civil engineers going back at least 4 generations, so this issue has been on my mind for a long time, trying to figure out whether I am "actually" an engineer and what that even might mean.)
posted by pmb at 6:57 AM on January 26, 2021 [17 favorites]
We don't have the analytical toolset to design software any other way, and we suffer in comparison to engineering disciplines that have worked hand-in-hand with mathematics and the physical sciences for centuries, but we are definitely doing what engineers did before they had the analytical tools necessary to do things differently.
(Disclosures: I have a PhD in computer science, am currently working as a software engineer, and come from a long line of civil engineers going back at least 4 generations, so this issue has been on my mind for a long time, trying to figure out whether I am "actually" an engineer and what that even might mean.)
posted by pmb at 6:57 AM on January 26, 2021 [17 favorites]
Frankly it was getting the Masters in Software Engineering that convinced me that the whole idea is dumb or at the very least premature. Designing and building software has nothing like the discipline of practice or predictability of outcome that other fields have. Maybe someday but not now.
posted by octothorpe at 7:02 AM on January 26, 2021 [3 favorites]
posted by octothorpe at 7:02 AM on January 26, 2021 [3 favorites]
"Hey, I'm just gonna take this backhoe and see if we can't find a better foundation site in the next lot over" said no construction engineer ever.
I've come close. And like the pullquote included in the article "I've had to move a bridge before", I've definitely experienced the condition described in the quote for this post of looking at moving an entire mostly-designed building on a site because of unforeseen soil conditions (an underground river). I'm working on one project where we're seriously looking at transplanting a mostly-designed building to a completely different site just because the utility situation at the site our client chose isn't what they thought it was.
posted by LionIndex at 7:03 AM on January 26, 2021 [3 favorites]
I've come close. And like the pullquote included in the article "I've had to move a bridge before", I've definitely experienced the condition described in the quote for this post of looking at moving an entire mostly-designed building on a site because of unforeseen soil conditions (an underground river). I'm working on one project where we're seriously looking at transplanting a mostly-designed building to a completely different site just because the utility situation at the site our client chose isn't what they thought it was.
posted by LionIndex at 7:03 AM on January 26, 2021 [3 favorites]
Are you certified by a professional body?
Do you take legal reasonability for your work? That is, do you (or your company for you) need to carry errors and omission insurance?
That's pretty much the definition of an engineer where I live. Lots of people without PE designations work in all kinds of engineering too, even with degrees in engineering. They just can't legally sign off on projects to clients.
posted by bonehead at 7:03 AM on January 26, 2021 [11 favorites]
Do you take legal reasonability for your work? That is, do you (or your company for you) need to carry errors and omission insurance?
That's pretty much the definition of an engineer where I live. Lots of people without PE designations work in all kinds of engineering too, even with degrees in engineering. They just can't legally sign off on projects to clients.
posted by bonehead at 7:03 AM on January 26, 2021 [11 favorites]
I recall a talk...that pointed out that engineers were building big arched bridges before we had calculus. They would build models of various sizes, break them, figure out the scaling laws, and then build the full-size bridge with confidence. I feel strongly that software engineers are engaging in at least this proto-engineering.
I kind of feel that software engineering is stuck in the practice of using the public to beta test bridges after they're built.
posted by Thorzdad at 7:05 AM on January 26, 2021 [14 favorites]
I kind of feel that software engineering is stuck in the practice of using the public to beta test bridges after they're built.
posted by Thorzdad at 7:05 AM on January 26, 2021 [14 favorites]
To clarify: it's not any of Hillel's six points that define a PE really, it's about taking legal responsibility for the work, of yourself and of your team. An engineer, like a doctor or a lawyer, is fully responsible for and can be sued for their work if something goes wrong. That's why "engineer" doesn't translate as a concept very well to software.
posted by bonehead at 7:08 AM on January 26, 2021 [5 favorites]
posted by bonehead at 7:08 AM on January 26, 2021 [5 favorites]
Iterative approaches to civil engineering were a lot more tenable back when you could test things with Thracian and Gallic slaves and just buy more if the wall came down.
The code of Hamurrabi took a stern stance against that kind of approach, which might explain why to this day Iraqi architecture looks a lot more cautious compared to Roman arches or Gothic cathedrals.
posted by ocschwar at 7:10 AM on January 26, 2021 [7 favorites]
The code of Hamurrabi took a stern stance against that kind of approach, which might explain why to this day Iraqi architecture looks a lot more cautious compared to Roman arches or Gothic cathedrals.
posted by ocschwar at 7:10 AM on January 26, 2021 [7 favorites]
It would be interesting to look and when and, to the extent you can, why CS programs migrated from colleges-of-arts-and-sciences to engineering schools, with that original placement of course not being universal. Being at base cynical, my own expectation is that this had a lot to do with the masculinization of the programming trade, both retrospectively and prospectively.
posted by GCU Sweet and Full of Grace at 7:11 AM on January 26, 2021 [4 favorites]
posted by GCU Sweet and Full of Grace at 7:11 AM on January 26, 2021 [4 favorites]
"Does software development have equivalents of finding a flowing artesian well (dig a hole, it starts to fill up with water basically forever)"
Arguably, that's exactly what's happened with spam, trolling, and malicious social engineering.
posted by Nancy Lebovitz at 7:14 AM on January 26, 2021 [7 favorites]
Arguably, that's exactly what's happened with spam, trolling, and malicious social engineering.
posted by Nancy Lebovitz at 7:14 AM on January 26, 2021 [7 favorites]
Version control is the single most innovative, most revolutionary, most paradigm-shifting tool that is uniquely ours
I'm pretty with him on this. Sure, everywhere I've worked has had a very formal system of document management, especially for drawings. But that's a distraction from what tools like git can do when managing all of the other stuff that goes into generating those final design documents. Honestly github and its ecosystem of project management stuff is a vastly superior to any of the enterprise pos I've used for work.
My experience is entirely in chemical and mechanical, but basically all calculations that are not done in some specialty software are done in excel. Invariably in a shared folder with names like "project abc {someone's initials} ver 1.xlsx" and it's always something of an open question of what's the most recent one and what was changed. It is always a mess and, to quote one of the engineers interviewed "there’s days that I am shocked skyscrapers don’t fall over daily and planes don’t crash." Putting all of this, the working files, into a real version control system, like software folks do every day, would be a dream.
posted by selenized at 7:27 AM on January 26, 2021 [11 favorites]
I'm pretty with him on this. Sure, everywhere I've worked has had a very formal system of document management, especially for drawings. But that's a distraction from what tools like git can do when managing all of the other stuff that goes into generating those final design documents. Honestly github and its ecosystem of project management stuff is a vastly superior to any of the enterprise pos I've used for work.
My experience is entirely in chemical and mechanical, but basically all calculations that are not done in some specialty software are done in excel. Invariably in a shared folder with names like "project abc {someone's initials} ver 1.xlsx" and it's always something of an open question of what's the most recent one and what was changed. It is always a mess and, to quote one of the engineers interviewed "there’s days that I am shocked skyscrapers don’t fall over daily and planes don’t crash." Putting all of this, the working files, into a real version control system, like software folks do every day, would be a dream.
posted by selenized at 7:27 AM on January 26, 2021 [11 favorites]
Do you take legal reasonability for your work? That is, do you (or your company for you) need to carry errors and omission insurance?
Yes, in large companies software engineers take responsibility for their work as do executives in compliance with Sarbanes Oxley, but I'm sorry it's as BS as engineers taking 'responsibility' for the bad things they design and the problems they cause. Some guy was just killed on the main street outside my house. Is some engineer going to jail for that? No he is not.
I kind of feel that software engineering is stuck in the practice of using the public to beta test bridges after they're built.
Here's a bridge that's uncrossable by pedestrians. Who's on the hook for it? The engineer? No he is not. Caltrava Bridge Dallas TX And get this - it's safe for cars but not for people. LOL.
posted by The_Vegetables at 7:29 AM on January 26, 2021 [1 favorite]
Yes, in large companies software engineers take responsibility for their work as do executives in compliance with Sarbanes Oxley, but I'm sorry it's as BS as engineers taking 'responsibility' for the bad things they design and the problems they cause. Some guy was just killed on the main street outside my house. Is some engineer going to jail for that? No he is not.
I kind of feel that software engineering is stuck in the practice of using the public to beta test bridges after they're built.
Here's a bridge that's uncrossable by pedestrians. Who's on the hook for it? The engineer? No he is not. Caltrava Bridge Dallas TX And get this - it's safe for cars but not for people. LOL.
posted by The_Vegetables at 7:29 AM on January 26, 2021 [1 favorite]
I wish more software folks had Hillel's level of introspection and rigor. I recommend his What We Know We Don't Know.
It's a long subject, but really shows where a lot of the weaknesses are in software engineering and research.
posted by SunSnork at 7:30 AM on January 26, 2021 [2 favorites]
It's a long subject, but really shows where a lot of the weaknesses are in software engineering and research.
posted by SunSnork at 7:30 AM on January 26, 2021 [2 favorites]
I recall a talk...that pointed out that engineers were building big arched bridges before we had calculus. They would build models of various sizes, break them, figure out the scaling laws, and then build the full-size bridge with confidence. I feel strongly that software engineers are engaging in at least this proto-engineering.
I think you mean proto-scientists...
My own definitions (and no one else's):
Scientist - developes knowledge based tools
Engineer - developes physcial tools
posted by 445supermag at 7:31 AM on January 26, 2021
I think you mean proto-scientists...
My own definitions (and no one else's):
Scientist - developes knowledge based tools
Engineer - developes physcial tools
posted by 445supermag at 7:31 AM on January 26, 2021
Not everybody who works with electricity is going to be an electrical engineer; many will be electricians. And this is okay.
I think he's missed a point about what "engineering" is, really. I've always thought of it as being on a spectrum with pure math on one end and "turning wrenches" on the other end. In other words:
Science is applied mathematics.
Engineering is applied science.
"Engineering tech" is applied engineering.
"Technology" is applied "engineering tech."
I'm using those last terms in quotes because I find them harder to define, but you can get a BA in "engineering technology" which is essentially how to apply the outputs of engineering to real world problems. In the electricity example, physicists apply mathematical principles to develop theories. Engineers take those theories and produce specifications, designs, and architecture. The electrical designer applies that output and lays out the wiring schematic for your house. The electrician installs the wires. Mechanical engineering (my background) has a similar hierarchy, where the people doing what the layperson might assume is "real engineering" (drawing blueprints, making CAD models, building prototypes) are highly skilled technicians, frequently without advanced degrees. The folks with the BS, MS, PhD calling themselves "mechanical engineers" are one level abstracted from that. These people, the "real engineers," may never touch tools in their entire careers.
And I think software has similar parallels. Software engineering is a real discipline that is applied... computer science? Like a lot of "real engineering" jobs, from the outside it looks a lot like management. The developers are applying the outputs of that software engineering process to create the specifications of the product that will be built. Coders are implementing the outputs of the developers in to a finished product.
posted by backseatpilot at 7:36 AM on January 26, 2021 [5 favorites]
I think he's missed a point about what "engineering" is, really. I've always thought of it as being on a spectrum with pure math on one end and "turning wrenches" on the other end. In other words:
Science is applied mathematics.
Engineering is applied science.
"Engineering tech" is applied engineering.
"Technology" is applied "engineering tech."
I'm using those last terms in quotes because I find them harder to define, but you can get a BA in "engineering technology" which is essentially how to apply the outputs of engineering to real world problems. In the electricity example, physicists apply mathematical principles to develop theories. Engineers take those theories and produce specifications, designs, and architecture. The electrical designer applies that output and lays out the wiring schematic for your house. The electrician installs the wires. Mechanical engineering (my background) has a similar hierarchy, where the people doing what the layperson might assume is "real engineering" (drawing blueprints, making CAD models, building prototypes) are highly skilled technicians, frequently without advanced degrees. The folks with the BS, MS, PhD calling themselves "mechanical engineers" are one level abstracted from that. These people, the "real engineers," may never touch tools in their entire careers.
And I think software has similar parallels. Software engineering is a real discipline that is applied... computer science? Like a lot of "real engineering" jobs, from the outside it looks a lot like management. The developers are applying the outputs of that software engineering process to create the specifications of the product that will be built. Coders are implementing the outputs of the developers in to a finished product.
posted by backseatpilot at 7:36 AM on January 26, 2021 [5 favorites]
Some guy was just killed on the main street outside my house. Is some engineer going to jail for that? No he is not.
That's a facile comparison and you know it.
Further, D&O insurance is also not the same thing as E&O insurance, so I don't know why you think accounting practices compliance is the same thing as professional malpractice.
posted by aramaic at 7:39 AM on January 26, 2021 [3 favorites]
That's a facile comparison and you know it.
Further, D&O insurance is also not the same thing as E&O insurance, so I don't know why you think accounting practices compliance is the same thing as professional malpractice.
posted by aramaic at 7:39 AM on January 26, 2021 [3 favorites]
"Does software development have equivalents of finding a flowing artesian well (dig a hole, it starts to fill up with water basically forever)"
Yes it does - memory leaks (even if you use a garbage-collected language/runtime/framework, if the low-level resources are not released correctly, you will still leak), overconsumption of storage, API's operating in undocumented or buggy ways. Chaotic interaction between different frameworks and runtimes.... Thread contention...
They sold us "agile" because software development was not "mature" or perfectly repeatable. The perfect example they used over and over again was ... the construction industry - with well known inputs and controlled outputs, perfect scheduling, no hidden issues to mitigate... (forgive me while I catch my breath and wipe the tears away from my eyes...)
Back in reality, any sufficiently complex project is going to have unforeseen issues.
posted by rozcakj at 7:40 AM on January 26, 2021 [2 favorites]
Yes it does - memory leaks (even if you use a garbage-collected language/runtime/framework, if the low-level resources are not released correctly, you will still leak), overconsumption of storage, API's operating in undocumented or buggy ways. Chaotic interaction between different frameworks and runtimes.... Thread contention...
They sold us "agile" because software development was not "mature" or perfectly repeatable. The perfect example they used over and over again was ... the construction industry - with well known inputs and controlled outputs, perfect scheduling, no hidden issues to mitigate... (forgive me while I catch my breath and wipe the tears away from my eyes...)
Back in reality, any sufficiently complex project is going to have unforeseen issues.
posted by rozcakj at 7:40 AM on January 26, 2021 [2 favorites]
Ian Bogost of Georgia Tech weighs in on the issue. For the record, I agree with him.
Without professional standards, liability for lapses in completeness, liability for bugs that cost customers money, and sanctions for engineers who fail to live up to their ethical obligations (I'm looking at you, Facebook "Engineers"), I'm going to keep calling software folks "coders" or "developers."
posted by tclark at 7:41 AM on January 26, 2021 [8 favorites]
Without professional standards, liability for lapses in completeness, liability for bugs that cost customers money, and sanctions for engineers who fail to live up to their ethical obligations (I'm looking at you, Facebook "Engineers"), I'm going to keep calling software folks "coders" or "developers."
posted by tclark at 7:41 AM on January 26, 2021 [8 favorites]
Re:
We don't have the analytical toolset to design software any other way, and we suffer in comparison to engineering disciplines that have worked hand-in-hand with mathematics and the physical sciences for centuries, but we are definitely doing what engineers did before they had the analytical tools necessary to do things differently.
and
It would be interesting to look and when and, to the extent you can, why CS programs migrated from colleges-of-arts-and-sciences to engineering schools, with that original placement of course not being universal. Being at base cynical, my own expectation is that this had a lot to do with the masculinization of the programming trade, both retrospectively and prospectively.
Computer science was originally a branch of mathematics, which is typically in a College of Arts and Sciences. CS programs migrated around the time that they tried to grow away from the mathematical roots, and make programs available to students without as much background in pure math. And then some software design/programming programs migrated away from 4-year universities or engineering schools to community colleges. But many smaller colleges and universities still have a combined department of math and computer science.
Given that, I'm not sure where the claim that software design doesn't have equivalent or better analytic toolsets for testing as physical engineering comes from. With larger software projects, tools from statistics rather than more straightforward algorithm analysis are going to be more helpful, as I understand it. That the tools exist doesn't mean they are widely known or used within the discipline, of course, and no doubt there are solid reasons for that which I, as a mathematician with some minor cs experience rather than an actual software developer, don't fully know about. But my impression is along the lines of what backseatpilot says - that the farther one gets from the "science" part of computer science, the less of the theoretical background one is taught and the greater the emphasis is on the applied part, so many developers these days may simply just not have been taught the analytical tools for software design that are available.
And I should probably go read the actual article that this post is about now :P
posted by eviemath at 7:50 AM on January 26, 2021
We don't have the analytical toolset to design software any other way, and we suffer in comparison to engineering disciplines that have worked hand-in-hand with mathematics and the physical sciences for centuries, but we are definitely doing what engineers did before they had the analytical tools necessary to do things differently.
and
It would be interesting to look and when and, to the extent you can, why CS programs migrated from colleges-of-arts-and-sciences to engineering schools, with that original placement of course not being universal. Being at base cynical, my own expectation is that this had a lot to do with the masculinization of the programming trade, both retrospectively and prospectively.
Computer science was originally a branch of mathematics, which is typically in a College of Arts and Sciences. CS programs migrated around the time that they tried to grow away from the mathematical roots, and make programs available to students without as much background in pure math. And then some software design/programming programs migrated away from 4-year universities or engineering schools to community colleges. But many smaller colleges and universities still have a combined department of math and computer science.
Given that, I'm not sure where the claim that software design doesn't have equivalent or better analytic toolsets for testing as physical engineering comes from. With larger software projects, tools from statistics rather than more straightforward algorithm analysis are going to be more helpful, as I understand it. That the tools exist doesn't mean they are widely known or used within the discipline, of course, and no doubt there are solid reasons for that which I, as a mathematician with some minor cs experience rather than an actual software developer, don't fully know about. But my impression is along the lines of what backseatpilot says - that the farther one gets from the "science" part of computer science, the less of the theoretical background one is taught and the greater the emphasis is on the applied part, so many developers these days may simply just not have been taught the analytical tools for software design that are available.
And I should probably go read the actual article that this post is about now :P
posted by eviemath at 7:50 AM on January 26, 2021
I am a Principle Engineer after spending years as a Senior Software Engineer. You bet it's engineering, just like the real engineers that everyone always talks about: having to stop constantly to make changes, frequent breakdowns, steam and smoke and noise. I guess software engineering is as close as I'll ever come to being a proper train engineer, but I'll take it.
posted by Cris E at 7:54 AM on January 26, 2021 [4 favorites]
posted by Cris E at 7:54 AM on January 26, 2021 [4 favorites]
There are many kinds of engineering. I absolutely agree that software engineering isn't the same as mechanical engineering. But civil engineering isn't the same as electrical engineering, either.
I was indifferent before this morning, but I'm at least half convinced now that software engineering probably really is some kind of engineering.
posted by Foosnark at 8:05 AM on January 26, 2021
I was indifferent before this morning, but I'm at least half convinced now that software engineering probably really is some kind of engineering.
posted by Foosnark at 8:05 AM on January 26, 2021
To expand on my thoughts, I'm not saying software engineering can't or shouldn't be a credentialed engineering profession, but usage of the term absolutely should come with a set of professional standards and obligations.
I'm also not saying that every piece of software should be held to rigorous professional engineering standards. That's not realistic. But for mission critical software, or even just "bespoke" software that someone is willing to pay the additional costs incurred by using credentialed software engineers to develop to professional engineering standards (with the associated ethical obligations and other liability), that should be an option.
posted by tclark at 8:12 AM on January 26, 2021 [1 favorite]
I'm also not saying that every piece of software should be held to rigorous professional engineering standards. That's not realistic. But for mission critical software, or even just "bespoke" software that someone is willing to pay the additional costs incurred by using credentialed software engineers to develop to professional engineering standards (with the associated ethical obligations and other liability), that should be an option.
posted by tclark at 8:12 AM on January 26, 2021 [1 favorite]
Here's a bridge that's uncrossable by pedestrians. Who's on the hook for it? The engineer? No he is not.
If my quick read of that is correct, I'm not familiar with this at all, the city is on the hook because they disregarded the engineering firm's advice on testing. I can't see how a court would find the firm at fault for the city's risky choices.
Engineering responsibility doesn't usually mean that someone goes to jail. It mean a civil dispute to figure out who has to pay what restitution to whom. Again exactly like a doctor being sued for malpractice. It's not exactly the same as fiduciary responsibility either.
posted by bonehead at 8:16 AM on January 26, 2021 [1 favorite]
If my quick read of that is correct, I'm not familiar with this at all, the city is on the hook because they disregarded the engineering firm's advice on testing. I can't see how a court would find the firm at fault for the city's risky choices.
Engineering responsibility doesn't usually mean that someone goes to jail. It mean a civil dispute to figure out who has to pay what restitution to whom. Again exactly like a doctor being sued for malpractice. It's not exactly the same as fiduciary responsibility either.
posted by bonehead at 8:16 AM on January 26, 2021 [1 favorite]
Author neglects an important point about licensure. When you're a licensed engineer, your first duty is to the public, then to your customer and your own business. This is often overlooked by critics of the profession.
posted by hypnogogue at 8:20 AM on January 26, 2021 [5 favorites]
posted by hypnogogue at 8:20 AM on January 26, 2021 [5 favorites]
Some guy was just killed on the main street outside my house. Is some engineer going to jail for that? No he is not.
That's a facile comparison and you know it.
It's not either. See, this is exactly what I'm talking about. Did some engineer come out and check the road to verify is safe? No they did not. So what does that insurance really mean, and what is it really insuring against?
posted by The_Vegetables at 8:32 AM on January 26, 2021
That's a facile comparison and you know it.
It's not either. See, this is exactly what I'm talking about. Did some engineer come out and check the road to verify is safe? No they did not. So what does that insurance really mean, and what is it really insuring against?
posted by The_Vegetables at 8:32 AM on January 26, 2021
the city is on the hook because they disregarded the engineering firm's advice on testing. I can't see how a court would find the firm at fault for the city's risky choices.
Again, if the engineer can make a recommendation but people are free not to follow, and the engineer still signs off on the road being useful for cars, what exactly is being indemnified? Engineers begin to sound a lot like lawyers, and a lot like software engineers offering the best-case scenarios for their products.
posted by The_Vegetables at 8:35 AM on January 26, 2021
Again, if the engineer can make a recommendation but people are free not to follow, and the engineer still signs off on the road being useful for cars, what exactly is being indemnified? Engineers begin to sound a lot like lawyers, and a lot like software engineers offering the best-case scenarios for their products.
posted by The_Vegetables at 8:35 AM on January 26, 2021
Do you take legal reasonability for your work? That is, do you (or your company for you) need to carry errors and omission insurance?
I get that some just people fuck around with WordPress plugins and whatever, but reading comments like the above makes it real clear that most people don’t actually know what software engineering really entails. Going to jail or getting sued for fucking up is often part of the job.
My father has been an embedded systems engineer for 40 years, and I’ve been more on the internet side of software engineering for 22 years now. And between the two of us, we can absolutely answer “yes” to all the smug “but does a software dude have to…???” gotcha questions that got thrown out here.
Hell, with my dad’s security clearances, it’s possible for him to get executed for treason. Try doing that while building a bridge.
My response to these sort of discussions is: sorry your protectionist cartel didn’t actually protect you, Mr. or Ms. Professional Engineer :-(
posted by sideshow at 8:35 AM on January 26, 2021 [4 favorites]
I get that some just people fuck around with WordPress plugins and whatever, but reading comments like the above makes it real clear that most people don’t actually know what software engineering really entails. Going to jail or getting sued for fucking up is often part of the job.
My father has been an embedded systems engineer for 40 years, and I’ve been more on the internet side of software engineering for 22 years now. And between the two of us, we can absolutely answer “yes” to all the smug “but does a software dude have to…???” gotcha questions that got thrown out here.
Hell, with my dad’s security clearances, it’s possible for him to get executed for treason. Try doing that while building a bridge.
My response to these sort of discussions is: sorry your protectionist cartel didn’t actually protect you, Mr. or Ms. Professional Engineer :-(
posted by sideshow at 8:35 AM on January 26, 2021 [4 favorites]
I have a degree in engineering, I have worked as an engineer for two decades, and I never have been nor ever will be a licensed professional engineer. It’s fine, because I work for a company doing product development. I won’t be signing off on bridge designs, but I didn’t go to school for civil engineering anyway.
You don’t have to have a license to be an engineer; I don’t care what Canada says.
posted by Huffy Puffy at 8:36 AM on January 26, 2021 [6 favorites]
You don’t have to have a license to be an engineer; I don’t care what Canada says.
posted by Huffy Puffy at 8:36 AM on January 26, 2021 [6 favorites]
eveimath, the claim that we lack the necessary analytical toolkit comes from the fact that nobody can articulate what the necessary toolkit actually is. Logicians say it's just logic. Analysts say it's just analysis. Statisticians say it's statistics. Combinatorialists say it is discrete math. I have heard of no claim that I ended up believing that X is the core of the thing, and I have looked very very hard. Everyone just says that the solution is obviously their own research area. I was a CS faculty member in a combined Math/CS department for half a decade (and helped them undergo mitosis into being just a CS department and just a math department). I assure you, it's not because I haven't talked with mathematicians, it's just that (so far) none of their answers have made sense.
Computers and computer programming represent a radical novelty, and one which we still do not know how to handle. For the interested mathematician, a nice stepping-off point could be "Social Processes and Proofs of Theorems and Programs" combined with the knowledge that the authors drastically understate the size and scope of the problem. If there is an isomorphism between proofs and programs (and there are many such constructible isomorphisms!), then what do we do with the fact that most mathematical proofs are at least a little incomplete and many are wrong in the details, and the fact that modern computer systems run on "proofs" that are 100+ million steps long? There's something deep here, and something radically new. We can't yet describe it well, because we don't know what it is yet, and our species' collective knowledge isn't there yet.
posted by pmb at 8:45 AM on January 26, 2021 [3 favorites]
Computers and computer programming represent a radical novelty, and one which we still do not know how to handle. For the interested mathematician, a nice stepping-off point could be "Social Processes and Proofs of Theorems and Programs" combined with the knowledge that the authors drastically understate the size and scope of the problem. If there is an isomorphism between proofs and programs (and there are many such constructible isomorphisms!), then what do we do with the fact that most mathematical proofs are at least a little incomplete and many are wrong in the details, and the fact that modern computer systems run on "proofs" that are 100+ million steps long? There's something deep here, and something radically new. We can't yet describe it well, because we don't know what it is yet, and our species' collective knowledge isn't there yet.
posted by pmb at 8:45 AM on January 26, 2021 [3 favorites]
Wow - it has been 21 years since "After the Gold Rush: Creating a True Profession of Software Engineering" was published? Man, am I old.
But - essentially little has changed - frankly, if anything it is far worse now than then. But - OTOH, I don't want to be a gatekeeper - more and more people are writing software, building IoT devices and product engineering is available to almost anyone with a 3d-printer. (Look at the recent thread about 'The Pill Bottle Project')
But... then you begin to look at things like data/security breaches that could have been avoided if people followed procedures and repeatable practices of "currently known patterns" (I don't like to say 'best practices' anymore)... We are still in the gold-rush phase - worse than ever, because the gold is people's minds, eyeballs and private information - and no one really seems to care, not legislators, and definitely not business. (Back to the 'Pill Bottle Project' - what about PLA not being 'food-safe'... Is that the domain of an engineer, or a doctor?)
There is something to be said for requiring licensed engineers to build software that can kill people accidentally on failure.
posted by rozcakj at 9:05 AM on January 26, 2021 [6 favorites]
But - essentially little has changed - frankly, if anything it is far worse now than then. But - OTOH, I don't want to be a gatekeeper - more and more people are writing software, building IoT devices and product engineering is available to almost anyone with a 3d-printer. (Look at the recent thread about 'The Pill Bottle Project')
But... then you begin to look at things like data/security breaches that could have been avoided if people followed procedures and repeatable practices of "currently known patterns" (I don't like to say 'best practices' anymore)... We are still in the gold-rush phase - worse than ever, because the gold is people's minds, eyeballs and private information - and no one really seems to care, not legislators, and definitely not business. (Back to the 'Pill Bottle Project' - what about PLA not being 'food-safe'... Is that the domain of an engineer, or a doctor?)
There is something to be said for requiring licensed engineers to build software that can kill people accidentally on failure.
posted by rozcakj at 9:05 AM on January 26, 2021 [6 favorites]
By the logic of engineering licensure, software project managers should also have a license and qualifications equivalent to architects, yes?
And software engineers should have legal protections if they tell their employers no, we absolutely must add (tests/CI/CD/source control/encrypted passwords/security/whatever) at a cost increase of $$$?
And employers not following those recommendations will face explicit legal and financial repercussions?
Come on, this is a structural issue. Haranguing software engineers about it isn't useful.
posted by SunSnork at 9:31 AM on January 26, 2021 [5 favorites]
And software engineers should have legal protections if they tell their employers no, we absolutely must add (tests/CI/CD/source control/encrypted passwords/security/whatever) at a cost increase of $$$?
And employers not following those recommendations will face explicit legal and financial repercussions?
Come on, this is a structural issue. Haranguing software engineers about it isn't useful.
posted by SunSnork at 9:31 AM on January 26, 2021 [5 favorites]
→
It was mostly a Soviet thing, but Peter Palchinsky was executed for disagreeing with Party orthodoxy. Many other engineers and scientists suffered in the sharashka system.
I do apologize if my comment came across as snark. I certainly don't subscribe to the "Real Engineers need multiple boxes to bury their mistakes" macho shit. But there aren't any software engineering projects that are over a century old, and popular reporting of old software/hardware projects ("ICBMs need floppy disks!") is almost universally negative. In structural and mechanical engineering, historic projects are typically revered: "They managed to do that with that?". Even colossal, national industry-destroying failures (see the UK's jet airliner advances halted by the Comet disasters) are studied and some learnings from them (like improving the understanding of fatigue strength and stress raisers, even developing the very first rudiments of computational finite element analysis, in studying the Comet's design flaws) are celebrated. It may be a cosy clique (I am a P.Eng, I'm not keen on the whole professional engineering system for many reasons, but my work pays me to stay certified, so ¯\_(ツ)_/¯) but there's something to be said for the established professions creating their own history over time.
posted by scruss at 10:06 AM on January 26, 2021 [3 favorites]
it’s possible for him to get executed for treason. Try doing that while building a bridge.
It was mostly a Soviet thing, but Peter Palchinsky was executed for disagreeing with Party orthodoxy. Many other engineers and scientists suffered in the sharashka system.
I do apologize if my comment came across as snark. I certainly don't subscribe to the "Real Engineers need multiple boxes to bury their mistakes" macho shit. But there aren't any software engineering projects that are over a century old, and popular reporting of old software/hardware projects ("ICBMs need floppy disks!") is almost universally negative. In structural and mechanical engineering, historic projects are typically revered: "They managed to do that with that?". Even colossal, national industry-destroying failures (see the UK's jet airliner advances halted by the Comet disasters) are studied and some learnings from them (like improving the understanding of fatigue strength and stress raisers, even developing the very first rudiments of computational finite element analysis, in studying the Comet's design flaws) are celebrated. It may be a cosy clique (I am a P.Eng, I'm not keen on the whole professional engineering system for many reasons, but my work pays me to stay certified, so ¯\_(ツ)_/¯) but there's something to be said for the established professions creating their own history over time.
posted by scruss at 10:06 AM on January 26, 2021 [3 favorites]
Some guy was just killed on the main street outside my house. Is some engineer going to jail for that? No he is not.
All depends on whether the death was caused by a negligent design, or not. Streets are designed to state/local agency-approved design standards. If someone dies on a standard-designed facility, there really isn't anything the engineer could have done.
But even if it was a faulty design, jail, probably not. Even the guy who designed the KC Hyatt lobby catwalk bridges was only "disbarred" and sued.
So what does that insurance really mean, and what is it really insuring against?
I've been party to an civil engineering E&O insurance claim before. More or less, one of our engineers made a mistake in the design of a freeway component that wasn't caught by internal QC or the state transportation agency's review, and asphalt started going into the ground. Once we figured that it couldn't be fixed cheaply and an entire ramp needed to be rebuilt, our E&O insurance was engaged to pay for the cost to the state to fix the construction.
posted by Buy Sockpuppet Bonds! at 11:21 AM on January 26, 2021 [1 favorite]
All depends on whether the death was caused by a negligent design, or not. Streets are designed to state/local agency-approved design standards. If someone dies on a standard-designed facility, there really isn't anything the engineer could have done.
But even if it was a faulty design, jail, probably not. Even the guy who designed the KC Hyatt lobby catwalk bridges was only "disbarred" and sued.
So what does that insurance really mean, and what is it really insuring against?
I've been party to an civil engineering E&O insurance claim before. More or less, one of our engineers made a mistake in the design of a freeway component that wasn't caught by internal QC or the state transportation agency's review, and asphalt started going into the ground. Once we figured that it couldn't be fixed cheaply and an entire ramp needed to be rebuilt, our E&O insurance was engaged to pay for the cost to the state to fix the construction.
posted by Buy Sockpuppet Bonds! at 11:21 AM on January 26, 2021 [1 favorite]
I'm going to go ahead and say this is one of those "intra-group differences can be as big as inter-group differences" situations. Why compare software to all other engineering types at once? To a team of chemical engineers designing a refinery, an electronics engineer designing a board for a coffee maker is basically indistinguishable from any given software engineer, in terms of iteration turnaround time, consequences of failure, project inertia, etc. And the same gulf exists within each field- e.g. writing safety systems in aircraft software vs programming an IoT cat-feeder.
Most of the schisms being debated hotly above exist within engineering too. Sure, if you're building a refinery and don't do a HAZOP you'll ensure the project is uninsurable, plus risk killing people and/or losing an enormous amount of money. And the person who made that decision will be legally on the hook if something does go wrong. But someone doing operations at say a paint factory isn't subject to anywhere near the same level of regulation. And I'm sure the dude programming some cryptocurrency exchange back-end is subject to none.
One thing that does terrify me is the state of software in chemical engineering. No, please don't require yearly firmware updates on your instrument. Particularly if it lives in some hard to get to place, likely buried in dust and gunk. And no, it won't be going on the internet. I prefer my fail states to be at least somewhat predictable.
posted by Jobst at 11:25 AM on January 26, 2021 [7 favorites]
Most of the schisms being debated hotly above exist within engineering too. Sure, if you're building a refinery and don't do a HAZOP you'll ensure the project is uninsurable, plus risk killing people and/or losing an enormous amount of money. And the person who made that decision will be legally on the hook if something does go wrong. But someone doing operations at say a paint factory isn't subject to anywhere near the same level of regulation. And I'm sure the dude programming some cryptocurrency exchange back-end is subject to none.
One thing that does terrify me is the state of software in chemical engineering. No, please don't require yearly firmware updates on your instrument. Particularly if it lives in some hard to get to place, likely buried in dust and gunk. And no, it won't be going on the internet. I prefer my fail states to be at least somewhat predictable.
posted by Jobst at 11:25 AM on January 26, 2021 [7 favorites]
The points about licensure are addressed in the very first article: the term "engineering," in English, is not the same as the legally-protected (in some jurisdictions) term. Out of the several dozen EEs and MEs I've worked with over the last 10 years, I'm not sure a single one had a PE license. I'm not sure optical engineering even has a PE licensing system. The ME who all the other MEs claimed was the best ME they ever knew didn't even have a high school diploma, and thus couldn't get a PE license. It's not even that we don't make safety-critical products -- there are plenty of ways, especially on the ME side, that our work could cause injury or death -- both to operators and to bystanders -- if done poorly.
Personally: not everyone who programs computers is doing software engineering, but there is a very real set of work that is software engineering. There is a big grey area that covers a lot of projects -- basic web sites, little apps, or the kinds of semi-professional hardware projects you see people building off of RasbPis or Arduinos, for example. There is also a lot of bad software engineering, even in "real" shops. None of that means that "software engineering is not Real Engineering."
(There is a third chunk of the field, Computer Science. If you want analogies, Computer Science is like Physics, Software Engineering is like Electrical Engineering, and programming is kind of like electrician work.)
popular reporting of old software/hardware projects ("ICBMs need floppy disks!") is almost universally negative.
I see plenty of positive reporting on things like the Apollo program, nuclear simulation, and other 50s/60s successes. In industry press, there are plenty of reports of "what went right" for particularly successful projects.
Even where there is negative reporting, I see a lot of "this system was great in its time, but is long overdue for an update" (SABRE) or "here is a costly mistake that we've learned from" (Y2K). Spectacular security risks like Heartbleed, Spectre, and Meltdown are thoroughly analyzed and explained.
In fact, Heartbleed is a pretty good example of the programming/software engineering divide: a lot of OpenSSL was written by academic computer scientists doing programming, with a poor understanding of the software engineering side; very few software engineers had touched the OpenSSL codebase because of the long-standing warning that "you shouldn't touch crypto code unless you really know what you're doing." Post-Heartbleed, a lot of actual software engineers started looking at OpenSSL and realized that the scary crypto part was pretty small, and the piles of gunk around the crypto was full of standard software engineering failures.
posted by reventlov at 11:28 AM on January 26, 2021 [5 favorites]
Personally: not everyone who programs computers is doing software engineering, but there is a very real set of work that is software engineering. There is a big grey area that covers a lot of projects -- basic web sites, little apps, or the kinds of semi-professional hardware projects you see people building off of RasbPis or Arduinos, for example. There is also a lot of bad software engineering, even in "real" shops. None of that means that "software engineering is not Real Engineering."
(There is a third chunk of the field, Computer Science. If you want analogies, Computer Science is like Physics, Software Engineering is like Electrical Engineering, and programming is kind of like electrician work.)
popular reporting of old software/hardware projects ("ICBMs need floppy disks!") is almost universally negative.
I see plenty of positive reporting on things like the Apollo program, nuclear simulation, and other 50s/60s successes. In industry press, there are plenty of reports of "what went right" for particularly successful projects.
Even where there is negative reporting, I see a lot of "this system was great in its time, but is long overdue for an update" (SABRE) or "here is a costly mistake that we've learned from" (Y2K). Spectacular security risks like Heartbleed, Spectre, and Meltdown are thoroughly analyzed and explained.
In fact, Heartbleed is a pretty good example of the programming/software engineering divide: a lot of OpenSSL was written by academic computer scientists doing programming, with a poor understanding of the software engineering side; very few software engineers had touched the OpenSSL codebase because of the long-standing warning that "you shouldn't touch crypto code unless you really know what you're doing." Post-Heartbleed, a lot of actual software engineers started looking at OpenSSL and realized that the scary crypto part was pretty small, and the piles of gunk around the crypto was full of standard software engineering failures.
posted by reventlov at 11:28 AM on January 26, 2021 [5 favorites]
This argument reminds me of the nonsense about Dr. Jill Biden not bring a “real” doctor because she doesn’t have an MD.
posted by Big Al 8000 at 11:32 AM on January 26, 2021 [3 favorites]
posted by Big Al 8000 at 11:32 AM on January 26, 2021 [3 favorites]
I spent about 20 years as a software developer and manager (no CS degree) and now own DevOps tools and strategy for 3000+ developers and testers and even more other folks. I've also spent a number of years as an agile coach and trainer, which if you hate agile you can relabel as "helping amazingly dysfunctional teams with command-and-control managers be less so". I don't know anything about physical engineering.
I'm not sure how important the "engineer" label is versus something like "software professional". "Uncle Bob" Martin, who wrote the famous Clean Code, gave a ranty talk about how developers should think of themselves as professionals and advocate for good practices instead of rolling over for the businesspeople. You're a doctor and you tell a patient he needs heart surgery for $50,000 and it's a 6 hour surgery. The patient asks what you can do for $10k. Not an option. Can you do it faster if you skip washing your hands? Not an option. So can you write this code without thinking about data privacy? Security? Scaling? Longevity? Not an option!
That sounds great unless you know that there are exactly zero businesses or government agencies where the software professionals are in charge. Raise your hand if you've begged a product owner for time to fix obscure bugs or upgrade and re-test the third party libraries your code uses, or make the app run on the latest version of Java. NO ONE CARES. Until the software "building" crashes to the ground. Then they care. That's the true dynamic.
Another issue is that the industry innovates too much. I've been to a conference where a speaker said "you should learn at least one new language a year to stay current". Really? Fuck you! You should go play with your dog and kids once in a while! We don't really need a bunch of different programming languages; a couple for interactive apps and a couple for functional or embedded systems. Same with UI frameworks. They have a lot of cool features, but they are "tech debt" by the time you build an app in them. Combine this with the fact that people write code using whatever their existing product teams use, and then if you have low employee turnover you end up in situations where 90% of your devs have been working on their assigned apps since before AWS existed (for example). When do they magically learn AWS and serverless architecture and rewrite all their apps instead of building new lucrative features? They don't!
There's also the incredible breadth of knowledge you'd need to be an all-in-one wrecking crew of a software "engineer". These people exist and are more common in startups wher you have to wear many hats, but I'm going to list some topics that I'd guess 80% of programmers don't know much about:
Encryption at test
Encryption in transit
Cloud architecture
Scalable design
Microservice architecture
Data privacy
Code optimization
InfoSec and security breaches
Third party library licensing
DevOps pipelines
How non-techincal people use computers
How old people use computers
How people with disabilities use computers
etc.
The old joke about this is "Q. What is a full stack developer? A. Someone who's bad at database design, component architecture, AND UX!"
Add all this together - the anti-tech power dynamic, the high rate of tech change (buildings don't have outlets or toilets anymore! That's so 2019!!), and the huge number of specialty areas - and I have to agree that it doesn't make sense to think about a unified "software engineer" who signs off on things. I don't know the answer to this ... but companies generally pay lip service to many of the important bits, and customers don't want to pony up till it's too late. How much are you paying for your Facebook Premium subscription with better searching and sorting and guaranteed data privacy? I thought so!
posted by freecellwizard at 11:46 AM on January 26, 2021 [9 favorites]
I'm not sure how important the "engineer" label is versus something like "software professional". "Uncle Bob" Martin, who wrote the famous Clean Code, gave a ranty talk about how developers should think of themselves as professionals and advocate for good practices instead of rolling over for the businesspeople. You're a doctor and you tell a patient he needs heart surgery for $50,000 and it's a 6 hour surgery. The patient asks what you can do for $10k. Not an option. Can you do it faster if you skip washing your hands? Not an option. So can you write this code without thinking about data privacy? Security? Scaling? Longevity? Not an option!
That sounds great unless you know that there are exactly zero businesses or government agencies where the software professionals are in charge. Raise your hand if you've begged a product owner for time to fix obscure bugs or upgrade and re-test the third party libraries your code uses, or make the app run on the latest version of Java. NO ONE CARES. Until the software "building" crashes to the ground. Then they care. That's the true dynamic.
Another issue is that the industry innovates too much. I've been to a conference where a speaker said "you should learn at least one new language a year to stay current". Really? Fuck you! You should go play with your dog and kids once in a while! We don't really need a bunch of different programming languages; a couple for interactive apps and a couple for functional or embedded systems. Same with UI frameworks. They have a lot of cool features, but they are "tech debt" by the time you build an app in them. Combine this with the fact that people write code using whatever their existing product teams use, and then if you have low employee turnover you end up in situations where 90% of your devs have been working on their assigned apps since before AWS existed (for example). When do they magically learn AWS and serverless architecture and rewrite all their apps instead of building new lucrative features? They don't!
There's also the incredible breadth of knowledge you'd need to be an all-in-one wrecking crew of a software "engineer". These people exist and are more common in startups wher you have to wear many hats, but I'm going to list some topics that I'd guess 80% of programmers don't know much about:
Encryption at test
Encryption in transit
Cloud architecture
Scalable design
Microservice architecture
Data privacy
Code optimization
InfoSec and security breaches
Third party library licensing
DevOps pipelines
How non-techincal people use computers
How old people use computers
How people with disabilities use computers
etc.
The old joke about this is "Q. What is a full stack developer? A. Someone who's bad at database design, component architecture, AND UX!"
Add all this together - the anti-tech power dynamic, the high rate of tech change (buildings don't have outlets or toilets anymore! That's so 2019!!), and the huge number of specialty areas - and I have to agree that it doesn't make sense to think about a unified "software engineer" who signs off on things. I don't know the answer to this ... but companies generally pay lip service to many of the important bits, and customers don't want to pony up till it's too late. How much are you paying for your Facebook Premium subscription with better searching and sorting and guaranteed data privacy? I thought so!
posted by freecellwizard at 11:46 AM on January 26, 2021 [9 favorites]
The irony about whether software engineering is engineering is that what makes the line of work a profession and not just a trade is the obligation to protect the interests of the client and the public at large, and the willingness to resign rather than shrug the obligation.
In just about every context where this issue comes up, the obligation is best carried out by saying "all needed safety safeguards will be implemented in hardware by the mechanical/electrical/civil/chemical engineering team member, or else I resign." Not because software engineering lacks the requirement to carry a hefty amount of domain knowledge in your head compares to the other guys. It's because their work product is inherently more difficult to tamper with than yours, so safeguards implemented by them will stay implemented.
posted by ocschwar at 12:39 PM on January 26, 2021 [2 favorites]
In just about every context where this issue comes up, the obligation is best carried out by saying "all needed safety safeguards will be implemented in hardware by the mechanical/electrical/civil/chemical engineering team member, or else I resign." Not because software engineering lacks the requirement to carry a hefty amount of domain knowledge in your head compares to the other guys. It's because their work product is inherently more difficult to tamper with than yours, so safeguards implemented by them will stay implemented.
posted by ocschwar at 12:39 PM on January 26, 2021 [2 favorites]
They would build models of various sizes, break them, figure out the scaling laws, and then build the full-size bridge with confidence.
And all this time I thought Calvin's dad was telling a tall tale!
posted by Greg_Ace at 12:51 PM on January 26, 2021 [2 favorites]
And all this time I thought Calvin's dad was telling a tall tale!
posted by Greg_Ace at 12:51 PM on January 26, 2021 [2 favorites]
Most of the schisms being debated hotly above exist within engineering too. [...]
Yes, totally, Jobst. This got me thinking about how the profession is licensed where I live (Alberta) because some of this is made very explicit in the application process to be a P.Eng. As part of that process anyone who applies has to have 4 years of relevant work experience and what is "relevant" is spelled out to be mostly design and where the consequences are (essentially) life and death. But in my experience most chemical engineers work in operations and maintenance and do hardly any design, and while if you work at a large plant processing hydrocarbons (for example) the consequences for nearly anything can be extreme, for a lot engineers that's just not the case. Which leads to a weird situation where, conceivably, you could have a job that requires a P.Eng. to do, legally, but which would not qualify you to get one if you did as an EIT.
Something I've often wondered about is whether or not there's any data showing that licensing actually improves public safety? I definitely see that stated everywhere as why P.Eng./PE designations exist and that engineering failures >100yrs ago motivated this change. But I've never seen anyone, you know, prove it. There are lots of differences across jurisdictions of who requires licensing and who doesn't and a century of data, that would naively seem to be a natural experiment.
posted by selenized at 1:07 PM on January 26, 2021
Yes, totally, Jobst. This got me thinking about how the profession is licensed where I live (Alberta) because some of this is made very explicit in the application process to be a P.Eng. As part of that process anyone who applies has to have 4 years of relevant work experience and what is "relevant" is spelled out to be mostly design and where the consequences are (essentially) life and death. But in my experience most chemical engineers work in operations and maintenance and do hardly any design, and while if you work at a large plant processing hydrocarbons (for example) the consequences for nearly anything can be extreme, for a lot engineers that's just not the case. Which leads to a weird situation where, conceivably, you could have a job that requires a P.Eng. to do, legally, but which would not qualify you to get one if you did as an EIT.
Something I've often wondered about is whether or not there's any data showing that licensing actually improves public safety? I definitely see that stated everywhere as why P.Eng./PE designations exist and that engineering failures >100yrs ago motivated this change. But I've never seen anyone, you know, prove it. There are lots of differences across jurisdictions of who requires licensing and who doesn't and a century of data, that would naively seem to be a natural experiment.
posted by selenized at 1:07 PM on January 26, 2021
Haha, guess who is dealing with a project in Alberta right now, from the US? Those damn CRN's are killing me.
There's usually an interesting mix of regulations that came about for public protection, and those that arose from some sort of protectionism or regulatory capture. I enjoy trying to spot which is which.
I know here in the US (probably varies a lot by state) there's a hard line between engineers who do work that directly affects the public, e.g. civil doing bridge foundations, structural designing some new apartments. They all need a PE stamp, are bound by ethical codes, and are liable for all sorts of stuff that warrants insurance. Whereas I can design and approve all sorts of stuff without being a PE, and except in matters of clear-cut negligence it'll be my employer (or the project owner) that takes the direct heat should something go wrong. Is there any such distinction anywhere within software engineering? What does RAGAGEP look like in software engineering, should one need to justify their work with it?
posted by Jobst at 1:58 PM on January 26, 2021 [1 favorite]
There's usually an interesting mix of regulations that came about for public protection, and those that arose from some sort of protectionism or regulatory capture. I enjoy trying to spot which is which.
I know here in the US (probably varies a lot by state) there's a hard line between engineers who do work that directly affects the public, e.g. civil doing bridge foundations, structural designing some new apartments. They all need a PE stamp, are bound by ethical codes, and are liable for all sorts of stuff that warrants insurance. Whereas I can design and approve all sorts of stuff without being a PE, and except in matters of clear-cut negligence it'll be my employer (or the project owner) that takes the direct heat should something go wrong. Is there any such distinction anywhere within software engineering? What does RAGAGEP look like in software engineering, should one need to justify their work with it?
posted by Jobst at 1:58 PM on January 26, 2021 [1 favorite]
>There's something deep here, and something radically new. We can't yet describe it well, because we don't know what it is yet, and our species' collective knowledge isn't there yet.
It seems clear that halting makes a search for proof difficult in the bigger systems, so divide-and-conquer remains a strong approach.
There's still a lot of undefined behaviour.
People write for the 'happy path' and don't anticipate any failure.
Error handling is always something the author has met before or can imagine going wrong -- where falling safely requires you to land in a stop-dead or redo-from-beginning position.
Optimal algorithms aren't chosen -- to avoid premature optimisation of small parts rather than the whole of the system, which can be fixed with iterative improvements: targetting bottlenecks in a processing chain to relieve the worst parts will reveal new weakest-chain-links and show relative optimisation.
The biggest gains I can see coming are from renting CPU time, memory volumes and network bandwidth. You have to secure your side of the system, you have to optimise it so it's not more expensive than it needs to be (profiling it so you have a model for what the bills are likely to be), and you have to keep track of what the entire Rube Goldberg machine (well, mine’s a Heath Robinson machine because I'm British) is doing with the expectation that parts will fail as the system will scale to meet demand.
FinOps will make a difference. The people running the systems will have to talk about what they do for what they cost.
posted by k3ninho at 2:49 PM on January 26, 2021 [1 favorite]
It seems clear that halting makes a search for proof difficult in the bigger systems, so divide-and-conquer remains a strong approach.
There's still a lot of undefined behaviour.
People write for the 'happy path' and don't anticipate any failure.
Error handling is always something the author has met before or can imagine going wrong -- where falling safely requires you to land in a stop-dead or redo-from-beginning position.
Optimal algorithms aren't chosen -- to avoid premature optimisation of small parts rather than the whole of the system, which can be fixed with iterative improvements: targetting bottlenecks in a processing chain to relieve the worst parts will reveal new weakest-chain-links and show relative optimisation.
The biggest gains I can see coming are from renting CPU time, memory volumes and network bandwidth. You have to secure your side of the system, you have to optimise it so it's not more expensive than it needs to be (profiling it so you have a model for what the bills are likely to be), and you have to keep track of what the entire Rube Goldberg machine (well, mine’s a Heath Robinson machine because I'm British) is doing with the expectation that parts will fail as the system will scale to meet demand.
FinOps will make a difference. The people running the systems will have to talk about what they do for what they cost.
posted by k3ninho at 2:49 PM on January 26, 2021 [1 favorite]
Been learning it, doing it and teaching it for 50 years. Software is a craft not engineering (and my wife, who is an engineer agrees) it might become engineering in the future but not right now.
posted by bifurcated at 12:59 AM on January 27, 2021 [4 favorites]
posted by bifurcated at 12:59 AM on January 27, 2021 [4 favorites]
I'm a programmer and computer scientist and I've been swearing up and down for all my decades that programming is a craft and "software engineering" is aspirational bullshit. But I have to say, as I've talked to civil and mechanical and electrical engineers... it doesn't sound as distinct as I'd have wished.
The civil engineers in particular sound awfully familiar in how they fail because nobody can get real requirements and they have dependencies on undocumented old shortcuts.
posted by away for regrooving at 1:45 AM on January 27, 2021 [1 favorite]
The civil engineers in particular sound awfully familiar in how they fail because nobody can get real requirements and they have dependencies on undocumented old shortcuts.
posted by away for regrooving at 1:45 AM on January 27, 2021 [1 favorite]
In the electricity example, physicists apply mathematical principles to develop theories. Engineers take those theories and produce specifications, designs, and architecture. The electrical designer applies that output and lays out the wiring schematic for your house. The electrician installs the wires.
Electrical installations don't work this way except in large projects and even there it is common for the electrician to reject a design because it is unsafe, impossible, or needlessly expensive. Then a better design is hashed out between the trade and the designers.
And practically no single family home or many multi family properties under say a 6-plex or commercial under a million or so will have an engineer or electrical designer involved in the electrical except at the remote stage of listed equipment design. Commonly an architect/designer specifies outlet (where outlet is electrician jargon for "a point in the wiring installation at which current is taken to supply utilization equipment") location only. But it is not uncommon for part or all of the entire installation to be at the electrician's discretion. And if plans exist changes are often specified by a change order after consultation with only the general contractor. I've done complete solo installs up to 1000 KVA (good size apartment block/strip mall) without consulting with anyone other than an inspector and in my jurisdiction while working under an Operating Permit I don't even get inspected for services under 45KVA (typical house).
I'd bet it is the same for plumbers, sprinkler installers, HVAC guys, and carpenters to single out a few.
In a way it is a lot like how a lot of software development is handled except trade workers don't have engineer in their job descriptions.
posted by Mitheral at 8:55 AM on January 27, 2021 [5 favorites]
Electrical installations don't work this way except in large projects and even there it is common for the electrician to reject a design because it is unsafe, impossible, or needlessly expensive. Then a better design is hashed out between the trade and the designers.
And practically no single family home or many multi family properties under say a 6-plex or commercial under a million or so will have an engineer or electrical designer involved in the electrical except at the remote stage of listed equipment design. Commonly an architect/designer specifies outlet (where outlet is electrician jargon for "a point in the wiring installation at which current is taken to supply utilization equipment") location only. But it is not uncommon for part or all of the entire installation to be at the electrician's discretion. And if plans exist changes are often specified by a change order after consultation with only the general contractor. I've done complete solo installs up to 1000 KVA (good size apartment block/strip mall) without consulting with anyone other than an inspector and in my jurisdiction while working under an Operating Permit I don't even get inspected for services under 45KVA (typical house).
I'd bet it is the same for plumbers, sprinkler installers, HVAC guys, and carpenters to single out a few.
In a way it is a lot like how a lot of software development is handled except trade workers don't have engineer in their job descriptions.
posted by Mitheral at 8:55 AM on January 27, 2021 [5 favorites]
PS: I think in a lot of cases software developers being classified as engineers was a wizard framing move by management. Management gives up a title which costs them nothing and in return they get developers to align with professional classes instead of craft workers and thereby neuter labour organization in company culture right from the start. Which directly leads to exploitation, always in crunch time development cycles, workplace and hiring discrimination against women and minorities, and suppressed wages and benefits.
posted by Mitheral at 9:08 AM on January 27, 2021 [3 favorites]
posted by Mitheral at 9:08 AM on January 27, 2021 [3 favorites]
This argument reminds me of the nonsense about Dr. Jill Biden not bring a “real” doctor because she doesn’t have an MD.
I mean, that was silly because the word for doctor literally comes from the Latin, docere, 'to teach', and has been used by PhD's for hundreds of years. I don't believe anybody is arguing that the word engineer comes from 'one who builds siege engines' and what is a computer person going to do, write an app? Like Uber, but for catapults? Or a social media platform that convinces half of the population that siege engines are a myth and that closing the city gates is Hurting The Economy?
posted by Comrade_robot at 9:31 AM on January 27, 2021 [2 favorites]
I mean, that was silly because the word for doctor literally comes from the Latin, docere, 'to teach', and has been used by PhD's for hundreds of years. I don't believe anybody is arguing that the word engineer comes from 'one who builds siege engines' and what is a computer person going to do, write an app? Like Uber, but for catapults? Or a social media platform that convinces half of the population that siege engines are a myth and that closing the city gates is Hurting The Economy?
posted by Comrade_robot at 9:31 AM on January 27, 2021 [2 favorites]
Like Uber, but for catapults
Your idea is intriguing to me, and I wish to subscribe to your newsletter.
posted by Greg_Ace at 10:55 AM on January 27, 2021 [4 favorites]
Your idea is intriguing to me, and I wish to subscribe to your newsletter.
posted by Greg_Ace at 10:55 AM on January 27, 2021 [4 favorites]
I mean, that was silly because the word for doctor literally comes from the Latin, docere, 'to teach', and has been used by PhD's for hundreds of years. I don't believe anybody is arguing that the word engineer comes from 'one who builds siege engines' and what is a computer person going to do, write an app? Like Uber, but for catapults?
SHUT UP AND TAKE MY MONEY.
posted by ocschwar at 3:48 PM on January 27, 2021
I don't believe anybody is arguing that the word engineer comes from 'one who builds siege engines' and what is a computer person going to do, write an app?
oh hi
or maybe you want moving siege engines
posted by Huffy Puffy at 3:51 PM on January 27, 2021 [1 favorite]
oh hi
or maybe you want moving siege engines
posted by Huffy Puffy at 3:51 PM on January 27, 2021 [1 favorite]
« Older For Music Theory nerds | Science Fiction Dictionary Newer »
This thread has been archived and is closed to new comments
When I was hired they called the software team "developers," but a few years ago they decided to rename our titles to "software engineer." So I guess they believe too.
posted by Foosnark at 4:59 AM on January 26, 2021 [2 favorites]