> In fact, in some Canadian provinces, titles in computing such as “software engineer,” “computer engineer,” and others containing “engineer” are (in principle) reserved for people licensed as engineers by the provincial engineering regulator.
A most rational stance. One we should enforce here in the US.
Edit: Yes, I'm arguing that Software Engineer should be a licensed profession, but programmer shouldn't, and would be a fine substitution in the cases where you didn't need rigor.
--
If I were an engineer, there's no way I would trust any interface to a control system for a water purification plant that connected to the internet and allowed for ingress of control. Just as an example.
The OPM hack of 2015[1] is the worst case, in terms of national security, that clearly proves no Engineers were involved in the design of their computer system. Ingress of control should be absolutely prohibited, and it wasn't. I don't know why that database was ever put into a computer, instead of filing cabinets in a vault, nor why it was ever connected to any other system, and not completely air-gapped in said vault, with manual controlled exfiltration of data upon request.
This is one of those silly suggestions that comes up repeatedly, and solves a non-problem: In both the U.S. and Canada there are many instances where work needs to be approved by a credentialed and legally licensed engineer. Banning the use of the job title “engineer” in the U.S. would not change anything. (It would run smack into the 1st amendment though… it’s legal for me to call myself the King of France, and the onus is on you to decide if that’s all the due diligence you need to do before engaging me in treaty negotiations.)
You probably couldn’t ban the term engineer completely. But states do have pretty wide latitude to regulate job titles. You can’t call yourself a Professional Engineer, Registered Nurse, CPA, or Psychologist for example.
I'm glad that Alberta has the common sense to allow the term 'Software Engineer' so that the engineer societies can't go around suing people like crazy.
SCADA (Supervisory control and data acquisition) goes back to the 50s with, yes, remote access. Security has never been a design factor (after all, how many people had mainframes in the 50s?).
There's internet-connected industrial control panels online where you can just connect to them on your browser or some tool and start clicking buttons.
it's probably just convenient because there's no auth or VPNs required. yippee!
The difference is for others than "engineers" (software developers), where there is an expectation of certain quality when they hear someone call themselves "engineer". Just like the title "doctor" carries a certain expectation.
Is it "language police" that if you say "bomb" on an airplane, people might take that very seriously and you might get in legal trouble? Is that people's personal "language preference" or might there be some other implication behind some of the words in some contexts?
"Doctor" is a funny one because physicians originally latched onto the term to try and give themselves the credibility where they previously had none. Its use in medicine is in a lot of ways similar to the software situation.
The USA company my Dad was at in the late 1970s had to change all their software "engineering" job titles because the State of Texas required the licensing of people that called themselves "engineers".
The revelation came up when my Granddad reminisced laughing at the absurdity of my Dad being promoted to a "Senior Software Developer" at the age of 28.
In an overwhelming majority of cases, I've found the root cause is simply Doing The Right Thing Costs More.
It isn't "filing cabinets in a vault" that costs more. It is hiring the people with the requisite experience, expertise and soft skills to navigate those conversations. It is pushing the technical boundaries so these decisions are automatically made upon the metadata carried along by the pieces of infrastructure we're pushing around the table. It is putting in place the appropriate regulatory frameworks with auditing enforcement that halt overzealous KPI-chasing executives from overriding the caution signals raised within their own organizations, without stifling innovation.
And many other prudential measures set aside for "move fast and break things". Which unfortunately in so many cases boil down to "externalize my costs onto someone else who hasn't yet figured out they're the patsy" in a massive shell game of "Don't tax you, don't tax me, tax that fellow behind the tree" attributed to long-serving U.S. Senator Russell B. Long of Louisiana.
So what about like "mechanical engineers" or "process engineers" or "hardware engineer" or "biomedical engineers" etc?
> I don't know why that database was ever put into a computer, instead of filing cabinets in a vault, nor why it was ever connected to any other system, and not completely air-gapped in said vault, with manual controlled exfiltration of data upon request.
I suspect this is not because of the fake engineers but rather because other forces, e.g. management wanted more efficiency and security was the last item on the list. I don't see how changing job titles would change anything here
FYI: Mechanical and hardware engineers, in the appropriate language of the country, are already protected engineering titles in a lot of European countries.
Calling yourself a „dipl. Ing. <X>“ would be a crime if you don’t possess the appropriate degree.
Yes, but at least in Germany the "Dipl." makes the difference. I think it'd be OK to call yourself a "Software Engineer" without a degree and this is what many people do.
AFAIK the actual reason why „Software Engineer“ is ok is because it’s in English.
Pretending to be an „Ingenieur“ is illegal unless you have the paper to back it up. But it doesn’t necessarily have to be a university paper, there are older trade papers that also work.
I think the OP was talking about licensing and regulation. Licensed engineers have more power to push back on management. It’s not perfect but giving a licensed engineer the legal authority to say “No this isn’t safe. I won’t sign off on it.” goes a long way in the civil engineering world.
Yes, because it's their signature that actually has the weight of expertise. Similarly, their ass will be on the line if something goes wrong, not the management's.
Does not fully stop the pressure ("we'll find another licensed engineer to retain"), but at least ensures a somewhat level playing field between expertise and investors.
Some mechanical engineers are "professional engineers". That title is a legal liability for messing up. While most of the work designing a skyscraper belongs to any civil engineer, it won't be built until a professional engineer puts his legal mark on it being safe. In turn a professional engineer has the power and legal responsibility to tell management no and he will win against all their pressure. (though sometimes that means the company builds nothing and goes out of business forcing him to find a new job)
Wrangling agentic code is more like an industrial process than craftspersonship.
You need to treat the code that arrived in response to your prompt as a raw material: just like some truckload of unrefined and unmolded "stuff", it just arrived at your factory door, and it is still in need of banging into shape.
Your job is to build and operate the machinery (which is also software) that turns raw slop into worthy output.
Determine the tolerances (eg. quality tolerance: how bug-free must this be to ship?) and then work out how you'll scale up and remove yourself from as much of the attainment of those tolerances as possible, given constraints.
Consider by way of analogy an industrial food factory that mass produces, say, pickled fish. The fish are caught and brought to the factory - that's your agent's first-draft output. Next the fish are put by hand on a belt to be dipped, fired, cured, etc. - that mix of by-hand steps and automated steps is where you'd be crafting the custom linting steps, making the code compiled and having the agent write tests that prove quality, playing with the work (testing the feature, bugfix etc. by hand) and bringing it further from slop to the level of quality that's needed. The amount of this you do is determined by constraints - cost, time, etc.
Now that you're sizing your efforts against constraints and using tolerances as a tool, you're making the transition in your role, from craftsperson to engineer.
It's sort of like a factory. But it's never going to be a lights-out factory. You should design, supervise and improve the process in line with constraints and tolerances provided by stakeholders. And leave perfectionism at the door. You can chase your own definition of perfection in your hobby time, or if you want to get paid for perfection, start your own business where you call the shots.
I think only some software work is engineering and if I call myself a software engineer (in regard to my employment), it’s because it’s actually “a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”. And not just paying lip service. Otherwise, I’m something else with or even without the word software in the title (even if I work with software). Outside of work, I inherently consider myself a software engine but if work requires it, I have no problems treating it as less.
If you can't select the proper saplings and branches with the right elasticity to build a powerful ballista in any region in Europe, or plan and direct a mine under a fortress wall, you can't call yourself an Engineer. PERIOD
Author begins by describing the complexity crisis that folks tried to address at 1968 NATO SEC but then talks about engineering as a problem-solving effort involving calculations and caches.
Is it a surprise the complexity crisis continues? Dependencies rage out of control in modern systems, creating all sorts of havoc, including security issues. The academy seems to have little interest in this.
The "complexity crisis" isn't a solvable problem. Complexity is a reality in software engineering just like wind loading is a reality in structural engineering. You can't "solve" the wind and you can't "solve" complexity. That's where engineering comes in.
Genuinely curious, what’s examples of engineering classes you had that the CompSci did not in those +2 years? Are you talking about a 3 year CompSci (bachelor level) vs a 5 year eng degree?
The grading rubric for all engineering units here in Australia require that students develop an understanding of ethics and professional practice. There are a number of units dedicated to teaching project work, legal, and business aspects of engineering.
Typically the software engineers also do more maths than CS students. Reasoning from first principles is an important skill for professional engineers to have.
I suspect that testing22321's program is what Steve McConnell called software _engineering_, as opposed to the software engineering program that I went to, which is aligned with McConnell's _software_ engineering.
There's a chapter on this in McConnell's Professional Software Development:
Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers.
His example of software _engineering_ was McMaster University in Canada, where the graduate could achieve licensure by taking and passing the appropriate exams. Courses include materials, thermodynamics, electricity and magnetism. His example of _software_ engineering was based on (an older version) of the program I went to at RIT, which covered courses in software project management, software engineering process, and a lot more software systems design. Both had similar math, computer science, and software development courses, but I suspect McMaster would have courses in linear algebra and multivariable calculus that I didn't have.
Are American developers missing something? We missed out on the opportunity to get licensed in the mid-2000s and 2010s. People who went to _software_ engineering programs probably couldn't pass an FE exam unless they took (and remembered) a bunch of courses that have little to do with building software and would fall outside their normal academic program. I'd say that the software _engineering_ programs that don't get into the nuances of how to manage organizations and teams building software systems are the ones missing useful knowledge.
I suspect it was statics and dynamics (2 courses), heat transfer, electrical circuit theory (2 courses), differential equations, and complex variables. Along with some pre-reqs.
In the past it was not uncommon for every 'engineering' degree to require the basic sophomore level classes for mechanical and electrical engineering. (inThePast = years<1990)
This is right. Not only are ethics courses required for accreditation, but ethics is built into a number of other courses. It was primarily the design courses, but there was usually at least a module on some kind of ethical failure in whatever system the course was covering, like embedded, enterprise, or whatever.
Ugh. It's called engineering because in the beginning each university built or bought one computer. That machine was either owned by the mathematics department or the electrical engineering department (for hopefully obvious reasons). Fast forward a few decades and we have the twin disciplines of Computer Science and Software Engineering.
For the past couple of months, I've been doing a deep dive into engineering and engineering philosophy, and I have some thoughts about this article.
The biggest thing I noticed was that, even though there was an acknowledgment of the lack of a singular definition of engineering, the definition used throughout was tied to a linear model of innovation. I've been able to trace this thinking to the 1920s, with a growth in popularity in the 1940s and 1950s. A prime example is Vannevar Bush's Science: The Endless Frontier. Although the report had some good outcomes, like leading to the establishment of the National Science Foundation, Bush's own autobiography acknowledged that this model was a disservice to engineers and engineering, as it led to many engineering accomplishments being touted as scientific achievements and scientists getting credit for the work of engineers in popular literature and the press.
There aren't too many other views of engineering out there. A handful of contemporary authors keep coming up: Florman, Vincenti, Ferguson, Koen, and Petroski. Most other things I've read tend to cite one or more of these authors and continue to build upon their foundations.
Picking up any one of the other perspectives on engineering would let you make another connection to the 1968 NATO conference. There were really three camps that offered definitions about what software engineering should be. People like Dijkstra, Hoare, Naur, and Wirth focused on applying mathematics and computer science and on theory building. McIlroy, Bauer, and Bemer looked at how software development could learn from industrial engineering and mass production. David and Ross emphasized practical problem solving. By the 1969 conference, the practical problem-solving piece had dropped out of focus, even though this is very closely related to how other engineering philosophers looked at engineering.
Another aspect from some of the engineering philosophers is the craft roots of engineering. This also tends to disprove the linear model of innovation. Engineering existed well before modern science, and there are several cases of engineering development without a robust scientific understanding of the principles that enable it. Modern science became a tool in the toolbox of modern engineers, but it's not a precursor to engineering. The craft roots have been there all along and were part of engineering education up into the early 1900s. This can tie back into Agile Software Development and the software craftsmanship movement of the 1990s and early 2000s.
The paragraph about application programming being removed from the debates in the 1960s misses a key point. In the 1960s, "software" was shorthand for "systems software", or the stuff provided by computer manufacturers to allow people to make their computers do stuff. Application programs were not really considered software until at least the 1970s. It's a bit nuanced, but there's a reason for excluding this group of people: it was seen as a different thing entirely.
Finally, no mention of Margaret Hamilton. Failing to even mention Hamilton and her use of software engineering as an aspiration to elevate programmers to the same status as the other engineering disciplines on the Apollo program misses a huge moment in the development of the idea of software engineering.
It's possibly too harsh because people that hang around here might be those engineers that actually exist. Although I am not sure those would be downvoting. But I've seen a lot of "senior software engineers" that do not understand the basics of the programming language they use every day. This sadly is really not a hyperbole. So the term is a lot of time just brand inflation and wishful thinking.
"Software engineering" is the corporate aspect concerned with the "right" way to do stuff, often picking inadequate analogies from physical manufacturing and traditional engineering. It builds the ungainly, monolith dinosaurs and the technical debt. It is OOP, enterprise Java with the abstract factories, MFC, "agile methodologies" and "agentic workflows". It creates the dogma and the ideologies.
"Programming" is the creative tinkering aspect where you start from scratch and approach a problem from a new light. This is how Unix was born. It is the 1000-line program that is composable, fun to read and write and will last a long time.
Your first point is describing "overengineering" which can also be a fatal problem in traditional engineering fields.
It's easy to overengineer in software because the marginal cost of materials and logistics is ~$0. Overshooting by a mile is free. That doesn't discount the value of proper software engineering.
In practice, most software engineering is overengineering. It is adherence to dogma on a wide corporate scale. It leads to an explosion of complexity and bad software. It is the "best practices" that you should agree with, in order to stay employable.
I notice that software-related professions tend be named after traditionally male-dominated fields, such as "software engineer" or "software architect" or even the "rock star programmer".
Which is strange since the original "computers" were predominately women[0] and I find writing software has much in common with activities that were historically at least coed, such as creating recipes or sewing patterns.
Yet we never hear of "software chefs" or "software tailors". Given how little many titular heads of software companies understand their product, "software nanny" would also be applicable.
Maybe it's cultural or geographic, but both "chefs" and "tailors" is similarly male dominated here (Serbia in Europe). Out of all the professions you bring up, architects are actually pretty evenly split here.
Obviously, what matters is where the term was coined, but I'd certainly suspect it has nothing to do with any gender bias and is instead about parallels to civil construction: architects design, engineers make it work and possible for builders to build. If anything, with LLMs, software engineers more closely match up to construction (as engineers rarely lay a single brick).
> In fact, in some Canadian provinces, titles in computing such as “software engineer,” “computer engineer,” and others containing “engineer” are (in principle) reserved for people licensed as engineers by the provincial engineering regulator.
A most rational stance. One we should enforce here in the US.
Edit: Yes, I'm arguing that Software Engineer should be a licensed profession, but programmer shouldn't, and would be a fine substitution in the cases where you didn't need rigor.
--
If I were an engineer, there's no way I would trust any interface to a control system for a water purification plant that connected to the internet and allowed for ingress of control. Just as an example.
The OPM hack of 2015[1] is the worst case, in terms of national security, that clearly proves no Engineers were involved in the design of their computer system. Ingress of control should be absolutely prohibited, and it wasn't. I don't know why that database was ever put into a computer, instead of filing cabinets in a vault, nor why it was ever connected to any other system, and not completely air-gapped in said vault, with manual controlled exfiltration of data upon request.
[1] https://en.wikipedia.org/wiki/2015_Office_of_Personnel_Manag...
This is one of those silly suggestions that comes up repeatedly, and solves a non-problem: In both the U.S. and Canada there are many instances where work needs to be approved by a credentialed and legally licensed engineer. Banning the use of the job title “engineer” in the U.S. would not change anything. (It would run smack into the 1st amendment though… it’s legal for me to call myself the King of France, and the onus is on you to decide if that’s all the due diligence you need to do before engaging me in treaty negotiations.)
You probably couldn’t ban the term engineer completely. But states do have pretty wide latitude to regulate job titles. You can’t call yourself a Professional Engineer, Registered Nurse, CPA, or Psychologist for example.
Commercial speech doesn’t enjoy absolute protection.
> You probably…
Yes, agreed but what is the point? What problem are we solving?
Regulation is the point.
You probably can't stop all smugglers You probably can't stop all teen pregnancies You probably can't stop all enshitification
But a well functioning society owes itself to try to keep itself accountable.
I'm glad that Alberta has the common sense to allow the term 'Software Engineer' so that the engineer societies can't go around suing people like crazy.
The infrastructure-getting-hacked thing is wild to me! Something went very wrong early in the design process!
SCADA (Supervisory control and data acquisition) goes back to the 50s with, yes, remote access. Security has never been a design factor (after all, how many people had mainframes in the 50s?).
So yes, from very early in the design process.
There's internet-connected industrial control panels online where you can just connect to them on your browser or some tool and start clicking buttons.
it's probably just convenient because there's no auth or VPNs required. yippee!
oi, you got a licence for that keyboard?
American employment licencing needs urgent review, and fewer licenced professions, not more.
So instance of SWE1 we become SWD1. I don't see the difference.
The difference is for others than "engineers" (software developers), where there is an expectation of certain quality when they hear someone call themselves "engineer". Just like the title "doctor" carries a certain expectation.
So language police.
It seems reasonable to want licensure on the belief that it raises quality.
It seems unreasonable to expect people to conform to your language preferences.
> So language police.
Is it "language police" that if you say "bomb" on an airplane, people might take that very seriously and you might get in legal trouble? Is that people's personal "language preference" or might there be some other implication behind some of the words in some contexts?
If you say "stop with the f-bombs" on a flight you might be in trouble only if you are misunderstood.
It's not about the word itself, it is about what it represents and the risk profile if it's true (nowhere to run to).
"Doctor" is a funny one because physicians originally latched onto the term to try and give themselves the credibility where they previously had none. Its use in medicine is in a lot of ways similar to the software situation.
Barber-surgeon doesn't have the same vibe, I suppose.
YES PLEASE, WHERE DO I SIGN.
The USA company my Dad was at in the late 1970s had to change all their software "engineering" job titles because the State of Texas required the licensing of people that called themselves "engineers".
The revelation came up when my Granddad reminisced laughing at the absurdity of my Dad being promoted to a "Senior Software Developer" at the age of 28.
> I don't know why that...
In an overwhelming majority of cases, I've found the root cause is simply Doing The Right Thing Costs More.
It isn't "filing cabinets in a vault" that costs more. It is hiring the people with the requisite experience, expertise and soft skills to navigate those conversations. It is pushing the technical boundaries so these decisions are automatically made upon the metadata carried along by the pieces of infrastructure we're pushing around the table. It is putting in place the appropriate regulatory frameworks with auditing enforcement that halt overzealous KPI-chasing executives from overriding the caution signals raised within their own organizations, without stifling innovation.
And many other prudential measures set aside for "move fast and break things". Which unfortunately in so many cases boil down to "externalize my costs onto someone else who hasn't yet figured out they're the patsy" in a massive shell game of "Don't tax you, don't tax me, tax that fellow behind the tree" attributed to long-serving U.S. Senator Russell B. Long of Louisiana.
This seems more like an argument for requiring licensure and not an argument for using the term engineer or not
So what about like "mechanical engineers" or "process engineers" or "hardware engineer" or "biomedical engineers" etc?
> I don't know why that database was ever put into a computer, instead of filing cabinets in a vault, nor why it was ever connected to any other system, and not completely air-gapped in said vault, with manual controlled exfiltration of data upon request.
I suspect this is not because of the fake engineers but rather because other forces, e.g. management wanted more efficiency and security was the last item on the list. I don't see how changing job titles would change anything here
FYI: Mechanical and hardware engineers, in the appropriate language of the country, are already protected engineering titles in a lot of European countries.
Calling yourself a „dipl. Ing. <X>“ would be a crime if you don’t possess the appropriate degree.
Yes, but at least in Germany the "Dipl." makes the difference. I think it'd be OK to call yourself a "Software Engineer" without a degree and this is what many people do.
AFAIK the actual reason why „Software Engineer“ is ok is because it’s in English.
Pretending to be an „Ingenieur“ is illegal unless you have the paper to back it up. But it doesn’t necessarily have to be a university paper, there are older trade papers that also work.
I thought so too, but I lost that argument a couple of years ago and was persuaded that "Ingenieur" alone can't be challenged.
Unfortunately I don't remember the details. I'd be happy to learn I was right after all;-)
I think the OP was talking about licensing and regulation. Licensed engineers have more power to push back on management. It’s not perfect but giving a licensed engineer the legal authority to say “No this isn’t safe. I won’t sign off on it.” goes a long way in the civil engineering world.
Yes, because it's their signature that actually has the weight of expertise. Similarly, their ass will be on the line if something goes wrong, not the management's.
Does not fully stop the pressure ("we'll find another licensed engineer to retain"), but at least ensures a somewhat level playing field between expertise and investors.
Some mechanical engineers are "professional engineers". That title is a legal liability for messing up. While most of the work designing a skyscraper belongs to any civil engineer, it won't be built until a professional engineer puts his legal mark on it being safe. In turn a professional engineer has the power and legal responsibility to tell management no and he will win against all their pressure. (though sometimes that means the company builds nothing and goes out of business forcing him to find a new job)
Wrangling agentic code is more like an industrial process than craftspersonship.
You need to treat the code that arrived in response to your prompt as a raw material: just like some truckload of unrefined and unmolded "stuff", it just arrived at your factory door, and it is still in need of banging into shape.
Your job is to build and operate the machinery (which is also software) that turns raw slop into worthy output.
Determine the tolerances (eg. quality tolerance: how bug-free must this be to ship?) and then work out how you'll scale up and remove yourself from as much of the attainment of those tolerances as possible, given constraints.
Consider by way of analogy an industrial food factory that mass produces, say, pickled fish. The fish are caught and brought to the factory - that's your agent's first-draft output. Next the fish are put by hand on a belt to be dipped, fired, cured, etc. - that mix of by-hand steps and automated steps is where you'd be crafting the custom linting steps, making the code compiled and having the agent write tests that prove quality, playing with the work (testing the feature, bugfix etc. by hand) and bringing it further from slop to the level of quality that's needed. The amount of this you do is determined by constraints - cost, time, etc.
Now that you're sizing your efforts against constraints and using tolerances as a tool, you're making the transition in your role, from craftsperson to engineer.
It's sort of like a factory. But it's never going to be a lights-out factory. You should design, supervise and improve the process in line with constraints and tolerances provided by stakeholders. And leave perfectionism at the door. You can chase your own definition of perfection in your hobby time, or if you want to get paid for perfection, start your own business where you call the shots.
I think only some software work is engineering and if I call myself a software engineer (in regard to my employment), it’s because it’s actually “a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”. And not just paying lip service. Otherwise, I’m something else with or even without the word software in the title (even if I work with software). Outside of work, I inherently consider myself a software engine but if work requires it, I have no problems treating it as less.
well said.
If you can't select the proper saplings and branches with the right elasticity to build a powerful ballista in any region in Europe, or plan and direct a mine under a fortress wall, you can't call yourself an Engineer. PERIOD
Using the engineering design process makes it engineering.
Hillel Wayne did a series of interviews with people who are considered "proper" engineers, which you can read here:
https://www.hillelwayne.com/tags/crossover-project/
the tl;dr is that for the most part, modern software development is very similar to engineering
Author begins by describing the complexity crisis that folks tried to address at 1968 NATO SEC but then talks about engineering as a problem-solving effort involving calculations and caches.
Is it a surprise the complexity crisis continues? Dependencies rage out of control in modern systems, creating all sorts of havoc, including security issues. The academy seems to have little interest in this.
The "complexity crisis" isn't a solvable problem. Complexity is a reality in software engineering just like wind loading is a reality in structural engineering. You can't "solve" the wind and you can't "solve" complexity. That's where engineering comes in.
You can certainly reduce unnecessary complexity and esp. dependencies
My degree is Software Engineering, and is fully accredited by the Australian Institute of Engineers.
It was two years longer than computer science, and all of those extra courses were with the “mainstream” Engineers.
Genuinely curious, what’s examples of engineering classes you had that the CompSci did not in those +2 years? Are you talking about a 3 year CompSci (bachelor level) vs a 5 year eng degree?
Can you elaborate on the extra courses? What are America's developers missing (I imagine ethics is glaringly missed)?
The grading rubric for all engineering units here in Australia require that students develop an understanding of ethics and professional practice. There are a number of units dedicated to teaching project work, legal, and business aspects of engineering.
Typically the software engineers also do more maths than CS students. Reasoning from first principles is an important skill for professional engineers to have.
I suspect that testing22321's program is what Steve McConnell called software _engineering_, as opposed to the software engineering program that I went to, which is aligned with McConnell's _software_ engineering.
There's a chapter on this in McConnell's Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers.
His example of software _engineering_ was McMaster University in Canada, where the graduate could achieve licensure by taking and passing the appropriate exams. Courses include materials, thermodynamics, electricity and magnetism. His example of _software_ engineering was based on (an older version) of the program I went to at RIT, which covered courses in software project management, software engineering process, and a lot more software systems design. Both had similar math, computer science, and software development courses, but I suspect McMaster would have courses in linear algebra and multivariable calculus that I didn't have.
Are American developers missing something? We missed out on the opportunity to get licensed in the mid-2000s and 2010s. People who went to _software_ engineering programs probably couldn't pass an FE exam unless they took (and remembered) a bunch of courses that have little to do with building software and would fall outside their normal academic program. I'd say that the software _engineering_ programs that don't get into the nuances of how to manage organizations and teams building software systems are the ones missing useful knowledge.
I suspect it was statics and dynamics (2 courses), heat transfer, electrical circuit theory (2 courses), differential equations, and complex variables. Along with some pre-reqs.
In the past it was not uncommon for every 'engineering' degree to require the basic sophomore level classes for mechanical and electrical engineering. (inThePast = years<1990)
> I imagine ethics is glaringly missed
You imagine wrong. Everyone I know with a software-engineering-type degree took a mandatory ethics course.
This is right. Not only are ethics courses required for accreditation, but ethics is built into a number of other courses. It was primarily the design courses, but there was usually at least a module on some kind of ethical failure in whatever system the course was covering, like embedded, enterprise, or whatever.
Has the engineering enhancement been beneficial in your work?
Ugh. It's called engineering because in the beginning each university built or bought one computer. That machine was either owned by the mathematics department or the electrical engineering department (for hopefully obvious reasons). Fast forward a few decades and we have the twin disciplines of Computer Science and Software Engineering.
I would argue that they are substantially different in definition, but blurred together in practice.
Computer Science is a science. It is not focused on building things; rather on learning things.
The "dot com boom" and subsequent 25 years had such an employment need that everything turned into "programming means FAANG means I am rich"
Business Data Processing and Management Information Systems is more applicable to a majority of the 'software engineers' today.
For the past couple of months, I've been doing a deep dive into engineering and engineering philosophy, and I have some thoughts about this article.
The biggest thing I noticed was that, even though there was an acknowledgment of the lack of a singular definition of engineering, the definition used throughout was tied to a linear model of innovation. I've been able to trace this thinking to the 1920s, with a growth in popularity in the 1940s and 1950s. A prime example is Vannevar Bush's Science: The Endless Frontier. Although the report had some good outcomes, like leading to the establishment of the National Science Foundation, Bush's own autobiography acknowledged that this model was a disservice to engineers and engineering, as it led to many engineering accomplishments being touted as scientific achievements and scientists getting credit for the work of engineers in popular literature and the press.
There aren't too many other views of engineering out there. A handful of contemporary authors keep coming up: Florman, Vincenti, Ferguson, Koen, and Petroski. Most other things I've read tend to cite one or more of these authors and continue to build upon their foundations.
Picking up any one of the other perspectives on engineering would let you make another connection to the 1968 NATO conference. There were really three camps that offered definitions about what software engineering should be. People like Dijkstra, Hoare, Naur, and Wirth focused on applying mathematics and computer science and on theory building. McIlroy, Bauer, and Bemer looked at how software development could learn from industrial engineering and mass production. David and Ross emphasized practical problem solving. By the 1969 conference, the practical problem-solving piece had dropped out of focus, even though this is very closely related to how other engineering philosophers looked at engineering.
Another aspect from some of the engineering philosophers is the craft roots of engineering. This also tends to disprove the linear model of innovation. Engineering existed well before modern science, and there are several cases of engineering development without a robust scientific understanding of the principles that enable it. Modern science became a tool in the toolbox of modern engineers, but it's not a precursor to engineering. The craft roots have been there all along and were part of engineering education up into the early 1900s. This can tie back into Agile Software Development and the software craftsmanship movement of the 1990s and early 2000s.
The paragraph about application programming being removed from the debates in the 1960s misses a key point. In the 1960s, "software" was shorthand for "systems software", or the stuff provided by computer manufacturers to allow people to make their computers do stuff. Application programs were not really considered software until at least the 1970s. It's a bit nuanced, but there's a reason for excluding this group of people: it was seen as a different thing entirely.
Finally, no mention of Margaret Hamilton. Failing to even mention Hamilton and her use of software engineering as an aspiration to elevate programmers to the same status as the other engineering disciplines on the Apollo program misses a huge moment in the development of the idea of software engineering.
> Application programs were really considered software until at least the 1970s
Did you mean "were not"?
Yes - fixed that. Thanks.
What makes software development engineering
Wishful thinking and brand inflation. Same thing that makes machine learning artificial intelligence.
It's possibly too harsh because people that hang around here might be those engineers that actually exist. Although I am not sure those would be downvoting. But I've seen a lot of "senior software engineers" that do not understand the basics of the programming language they use every day. This sadly is really not a hyperbole. So the term is a lot of time just brand inflation and wishful thinking.
"Software engineering" is the corporate aspect concerned with the "right" way to do stuff, often picking inadequate analogies from physical manufacturing and traditional engineering. It builds the ungainly, monolith dinosaurs and the technical debt. It is OOP, enterprise Java with the abstract factories, MFC, "agile methodologies" and "agentic workflows". It creates the dogma and the ideologies.
"Programming" is the creative tinkering aspect where you start from scratch and approach a problem from a new light. This is how Unix was born. It is the 1000-line program that is composable, fun to read and write and will last a long time.
Your first point is describing "overengineering" which can also be a fatal problem in traditional engineering fields.
It's easy to overengineer in software because the marginal cost of materials and logistics is ~$0. Overshooting by a mile is free. That doesn't discount the value of proper software engineering.
In practice, most software engineering is overengineering. It is adherence to dogma on a wide corporate scale. It leads to an explosion of complexity and bad software. It is the "best practices" that you should agree with, in order to stay employable.
I notice that software-related professions tend be named after traditionally male-dominated fields, such as "software engineer" or "software architect" or even the "rock star programmer".
Which is strange since the original "computers" were predominately women[0] and I find writing software has much in common with activities that were historically at least coed, such as creating recipes or sewing patterns.
Yet we never hear of "software chefs" or "software tailors". Given how little many titular heads of software companies understand their product, "software nanny" would also be applicable.
[0] https://www.smithsonianmag.com/science-nature/history-human-...
Maybe it's cultural or geographic, but both "chefs" and "tailors" is similarly male dominated here (Serbia in Europe). Out of all the professions you bring up, architects are actually pretty evenly split here.
Obviously, what matters is where the term was coined, but I'd certainly suspect it has nothing to do with any gender bias and is instead about parallels to civil construction: architects design, engineers make it work and possible for builders to build. If anything, with LLMs, software engineers more closely match up to construction (as engineers rarely lay a single brick).