There's something to be said about separating out engineering from development. As someone who went through the rigmarole of Canada's engineering test (though I never formally adopted the title of engineering because of the reporting requirements), there's something to be said of how considerate and thoughtful "engineering" is.
To become an engineer in Canada, you need to learn and commit to understanding in full every major engineering disaster in the country in the last 100 years, and how a failure in your duty as an engineer can actually kill people.
I feel like we could split software engineering from software development and gain a lot in our industry. Not all development needs to be engineering, but some absolutely does.
It makes sense why there's no software engineering then. If a requirement would be to have to learn about every software engineering disaster in the last 10 years, let alone the last 100 years, no one would have time to finish the course.
If we count disasters as those involving loss of life, I'm pretty sure we did learn about Therac-25 [1], one of Canada's major software disasters resulting in actual deaths.
We still treat documentation as a third class citizen.
We still allow stakeholders to pressure at the cost of long term security and sanity.
Important and rigid business rules, the most obvious candidates for automated tests, still go untested.
Access to critical parts is still open and backups are lacking. You can probably do a lot of damage without any malicious intent in many places if you're not careful.
I can go on. Funny thing is, these things still happen in companies which try to adhere to some kind of outside standard. Most CS classes talk about security vulnerabilities and cancelled software projects costing millions, but never go in depth. Even our research is lacking.
What we learned is no one cares until the costs are higher than the gains, excepting a few critical fields I'd wager 99% of software "engineers" will never step foot in.
This. Management does not care. Does the market care? In spite of examples like the Therac disaster, the people in charge do not try to learn about what it'd take to make software more truly reliable.
In the early part of my career, I (and many of my friends) invested significant amounts of our time learning and pushing PL/T because the way things were going:
- Things are toys before they become tools. Early word processors were toys util they replaced typewriters.
- As the tools become more important, they will become more mainstream. Requirements will increase, e.g. that they be more reliable, that they become more usable.
- We now have designers in tech, indicating that the market cares about usability.
- There is still no formal verification of software, just "tests" which are applied in varying degrees of completeness.
To rely on "testing" is fine for a lot of consumer applications, but when I briefly worked in medical devices, we used C++. We did not hire a specialist with experience in Coq. Similarly when I worked with medical data.
I'll be quite blunt and cynical about it. Don't blame the software "engineers" / developers / whatever you want to call us. One of my friends actually went back to school to do research on this stuff, but I'm pretty sure he made a pittance compared to the friends who worked on the like button at Facebook. The market doesn't care. Call me a software designer if you like, I'll take the fat paycheck after spending the entire early part of my career trying to make things reliable, only to be slotted into the same "tech bro" category by a society that doesn't care.
They did say major, not all engineering disasters.
At university, we were required to take a computer scientists & the society course, which software development disasters and ethics were the main part of the course. The Therac-25 case is a timeless classic, but there's others too. All software engineers should learn about past failures.
I don't think each civil engineer studies every bridge that's ever collapsed. Generally this sort of thing is handled by looking at case studies that represent particular failure modes.
You don't need to know about every disaster, but even just the Therac-25, the Mars Climate Orbiter, or Knight Capital would cover a fairly wide variety of root causes and real-world consequences.
1) You would have to pay these real engineers with licenses more for this to make sense. Currently most jobs that even make mention of this requirement pay well under what the software development equivalent would make
2) Companies don't like to hire "Real" engineers wherever possible because like all bureaucracy, sometimes they prevent projects moving forward. Companies are incentivized to employ the bare minimum of licensed individuals to sign off on the cheaper and faster work of the unlicensed proletariat. and pressure is put on the licensed to rubber stamp things.
3) I have found a lot of the courses in engineering school about ethics etc to be extremely rubber stamp/"mandatory safety training" ish, just like the dumb what's a stop sign test at the DMV. I doubt people en masse remember what they learn. I see it as a complex ruse to make people do the equivalent of sign a legal document saying "I accept the terms of this agreement and have the capacity to do so", more of "something that can be taken away if bad things happen" than "something to prevent bad things from happening"
> 1) You would have to pay these real engineers with licenses more for this to make sense. Currently most jobs that even make mention of this requirement pay well under what the software development equivalent would make
> 2) Companies don't like to hire "Real" engineers wherever possible because like all bureaucracy, sometimes they prevent projects moving forward. Companies are incentivized to employ the bare minimum of licensed individuals to sign off on the cheaper and faster work of the unlicensed proletariat. and pressure is put on the licensed to rubber stamp things.
These are reasons why companies might not want to hire engineers, but also reason why we might not want to do business with those sorts of companies. The fact that lots of companies seem to have gotten away with this stance seems to indicate a failure somewhere.
> 3) I have found a lot of the courses in engineering school about ethics etc to be extremely rubber stamp/"mandatory safety training" ish, just like the dumb what's a stop sign test at the DMV. I doubt people en masse remember what they learn. I see it as a complex ruse to make people do the equivalent of sign a legal document saying "I accept the terms of this agreement and have the capacity to do so", more of "something that can be taken away if bad things happen" than "something to prevent bad things from happening"
Yeah kinda. In defense of this sort of thing, going on to get a professional engineering license is definitely not something that all engineering students do. Many go on to do jobs that are more like programmers or technicians, right? Maybe the typical engineering degree should be renamed to pre-enginnering or something, but something tells me getting universities on board with that will be... challenging!
> commit to understanding ... how a failure in your duty as an engineer can actually kill people
I remember sitting in computational methods in uni while our professor was motivating the lesson on condition numbers, mentioning this is the kind of thing that can kill people, and students laughing at him.
Wish I could say that now that I've been in industry around a decade that the people around me have matured, but just as many still don't seem to care about quality.
Way too many people just chasing dollars and prestige with no appreciation for the power they wield.
> To practice engineering and use the title engineer (or any variation), you must be licensed by the engineering regulator for the province/ territory where the title is being used. Regulation minimizes risks to public safety and ensures that these activities are conducted by licensed engineers who are held to high professional and ethical standards that require them to work in the public interest.
I'm sure these bodies can provide evidence that people who have paid their membership dues and been bestowed the title of "engineer" write safer and better code, right?
Here's a perfect example of such regulatory corruption – https://ij.org/press-release/oregon-engineer-wins-traffic-li.... Someone ran tests and showed that Oregon's red light cameras were flawed. The state in turn fined him for calling himself an "engineer" without a license and barred him from speaking about the problem. Thankfully the supreme court put an end to it pretty quick.
>I'm sure these bodies can provide evidence that people who have paid their membership dues and been bestowed the title of "engineer" write safer and better code, right?
Having an engineering license means that you know the person when through a full college degree and/or could prove they have enough experience to compensate for it (not that easy btw). In Canada, it's not enough to just get a "major" in something related to engineering, they are a completely separate category of programs that have 1.5x the number of credits (>120 instead of 90) and are roughly equivalent to getting a Bachelor + master in other disciplines (it's 4 years, full-time, with full-time internships and/or classes during summers. 5 years if you want your summer off)
It also means that they can lose that title if they fuck up badly and get reported. You can't change the name of the company or create a new online account to escape that bad rep. The tone of the discussion is completely different when the person being pressured to sign something they shouldn't by a manager is risking their entire career over it.
Asking for an engineering stamp on something means that you know a specific person will be personally responsible for it. They can't get out of it with a cute letter about how they will investigate and take proper actions for the future.
Licensed engineering is an anachronism for most things. Because a licensed engineer put his seal on a drawing isn't good enough.
Modern engineering is all about standards and process.
Reminds me. One of the reasons California has high building costs and lack of construction workers is they went way overboard on contractors licensing.
What is too aggressive about this is the taking a normal english word and restricting its use to preserve a guild's privileges. The original sorta useful aspect of this was that in the days before the internet, you could keep records of the person doing the survey or signing off on the structural engineering. Now it's not even useful for that.
It would be far better if only "Licensed Software Engineer" was restricted. Most hiring managers would also, of course, be less likely to hire that person, just as "Certified Scrum Master" is a negative signal.
I've always thought it was a bit strange that in the US, the engineer who designs the mechanical parts of your car's brakes needs a professional license, but the engineer who writes the software doesn't.
Before you can license a group you need objective standards. Physical parts are easily translatable into standards with science and testable experiences. Software can fall into this category or they could be black boxes like AIs
Not mechanic as in the person that services brakes, but Mechanical Engineer as in the person engineering them.
Mechanical Engineers in the US are usually expected to be Professional Engineers (professional license) and in good standing with ASME, the American Society of Mechanical Engineers (professional society).
The people who need the P.Eng. qualification get it and the ones who don't need it tend not (why do all that extra effort if its not required). So that just means more civil engineering positions require it than mech eng positions.
For some types of software its the code development and testing process is highly regulated, for example aircraft avionics. In this case it doesn't really matter the qualifications of the person who wrote it provided the resulting code met all the process and testing requirements.
This must be enforced only on an adhoc basis when complaints are filed, or only in certain jurisdictions.
In BC, I have worked as a "Software Engineer" for 15 years with just a Bachelors and no engineering license, including for large tech companies. It's on my CV/LinkedIn. SE is the standard title internally and externally, it's on job postings, it's used everywhere.
You can do that, but you can't sign off on any documents as an engineer. You also won't eligible to write your P. Eng exam unless you've worked under a licensed engineer.
If this is true, it's changed in the last decade. I was able to write the engineering exam right out of school to become an "engineer in training". Becoming a full P. Eng required experience, but no exam.
Court case: In an oral decision delivered on November 26, 2019, Associate Chief Justice Nielsen of the Alberta Court of Queen’s Bench ordered an injunction against an individual who was using the title “Software Engineer” in his online profiles, despite the fact he was not an APEGA member. Associate Chief Justice Nielsen found that by holding himself out to the public as a “software engineer”, this individual could by implication lead a member of the public to conclude he is a professional engineer, licensee or permit holder with APEGA. This was a violation of s. 3(1)(a)(ii) of the Engineers and Geoscience Professions Act. Associate Chief Justice Nielsen granted the injunction order sought by APEGA and awarded costs to APEGA for the contested application.
Court case: On 10 March 2020, the Quebec Superior Court (2020 QCCS 1465) upheld a lower court ruling, finding an individual guilty of improperly using the French abbreviation “ing.” In e-mails sent to clients and colleagues, and on a résumé sent to a prospective employer. The Court found that the use of “ing.” by an individual not registered with Quebec’s governing body would induce a reasonable person to conclude that the individual is indeed an engineer. As a result, the individual was found guilty of 4 counts of improper use of title. Leave to appeal was denied by the Quebec Court of Appeal on 5 June 2020 (2020 QCCA 730).
My point was more that the majority of public job descriptions use "Software Engineer" as the title. The vast majority of engineers I have ever worked with call themselves Software Engineers.
And one of the main examples in the article is an injunction against an individual for using that title online?
This is a nothingburger. Here is the quote that matters:
> Unless someone is licensed with a provincial or territorial engineering regulator, they cannot use the title engineer, or any variation.
So, you can legally call yourself a software engineer if you have your title. There are laws like this in most countries regarding medical doctors. This prevents Doctor of Acupuncture from appearing.
You can call yourself a software engineer. You just need to have qualified with the professional body in charge of engineering. Like, say, a doctor or a lawyer.
Software lawyer sounds like you're a lawyer with a specialization. But ultimately I think it shouldn't come down to the specifics of what you call yourself since that's something people can weasel out of, but rather if you're communicating that you provide professional legal services.
as does "software engineer", but the title could be used in the US by someone who graduated a code boot camp, and doesn't know any engineering principles.
Programmers write the code, though. A better name might be "software legislator." Given that lots of us work on top of a giant, partially-understood heap of frameworks and libraries, that might actually be a more appropriate name than Software Engineer.
What about writing code for decentralized contracts, since contracts are lawyery but I’m writing software and have no formal legal background or credentials? Surely no one would object to me using the term “lawyer” for that!
I dunno actually, do you need to be a lawyer to write a contract? I think anyone can do it, right? You just might screw yourself over by missing an edge case or writing an unenforceable contract.
Feel free to just drop the "software" part, since it's a mouthful, and just call yourself a "lawyer." What's the difference anyway, we're all just typing words and numbers into computers at the end of the day.
The title is wrong. You can call yourself a software engineer, as long as you're actually a professional engineer, licensed by a governmental regulator. Most engineering schools in Canada have a "software engineering" program (in addition to "computer science") and this program qualifies as prerequisite to become a licensed engineer.
I graduated through such as program and never bothered to apply for the license thing, because the money to be made as a software engineer isn't in Canada, and no one in the US would care or do anything to help me fulfill the reporting requirements that a P.Eng requires. And for what benefit? There's no benefit.
There's no demand for a Software P.Eng. One day there will be, when society recognizes that some code shouldn't be written by just any random person. That day isn't near, in my opinion.
> Claiming to be an engineer without being licensed is against the law. Titles such as Professional Engineer, Professional Licensee (engineering), P. Eng., P.L. (Eng.), or any title including the word engineer or a related abbreviation can only be used by those who are licensed.
Technically, it is not illegal.
> There are several places where the use of engineer is often used improperly. They include:
Software or data engineer: Unless someone is licensed with a provincial or territorial engineering regulator, they cannot use the title engineer, or any variation. This applies even if the title is assigned by the employer. Alternative titles can include:
> Every person who is not a holder of a licence or a temporary licence and who,
> (a) uses the title “professional engineer” or “ingénieur” or an abbreviation or variation thereof as an occupational or business designation;
> (a.1) uses the title “engineer” or an abbreviation of that title in a manner that will lead to the belief that the person may engage in the practice of professional engineering;
> (b) uses a term, title or description that will lead to the belief that the person may engage in the practice of professional engineering; or
> (c) uses a seal that will lead to the belief that the person is a professional engineer,
> is guilty of an offence and on conviction is liable for the first offence to a fine of not more than $10,000 and for each subsequent offence to a fine of not more than $25,000.
My current employer doesn't allow "Engineer" in someone's title unless they have a PE and are in good standing with their professional society. The company employs a lot of especially Civil Engineers for what it does and making that a job title guarantee across the company, including those of us in software, goes a long way in sending the right message to clients.
I've gotten some strange resume questions about why my current resume doesn't use "Engineer" in the title, and I worry some potential readers might misconstrue why my title is different in my current role, but also I went to a "proper" Engineering school (and have an MEng), might have taken the PE if the Software PE existed when I graduated (and if I had thought it might help my salary prospects, which currently in this industry it likely wouldn't) and I have a deep appreciation for what the professional licenses and professional societies do for the other engineering fields. Sometimes I think the software industry could use more of that and it would be good for everyone.
The definition of engineering is very broad. I'm glad it's not merely reserved for, "safety critical." However, "safeguarding economic interests," is... basically any business that operates software as a service or creates software for commercial use. Hopefully we won't have to test jurisprudence on this but sheesh.
In Ontario the PEO requires an academic component to qualify. Super. So I have twenty years of industry experience and probably know more about the state of the art than what is taught in any of the CAEB programs...
> Please note, there are currently zero graduate degree engineering programs accredited by the CEAB.
Never mind, you can't even get into a program that grants this requirement.
Presumably you might be able to squeeze in under the experience requirement? It's unclear.
It's also unclear why anyone would go through this process. The academic requirement will ensure you live with at least a decade worth of crushing debt for a job market that would basically avoid you if you put the designation on your resume. As far as I can tell there are few commercial institutions that wouldn't be better off hiring a non-P.Eng and can still operate their business with significant disregard for the economic interests of society.
I'm all for finding a way to bring a useful form of liability into our industry to protect people from the rampant fraud, data brokering, security leaks, and general, "lol break things, disrupt society, make money," trends. However I think, unless I'm mistaken, there ought to be a way to bring people into the designation who have the industry experience but lack the academic requirement and, more importantly, the companies have a reason to hire P.Eng's and pay attention to them.
It's pretty easy to think that software is basically designing search engines and providing a place for someone to play Farmville. But keep in mind that there are many places where software and automation plays an integral role in a process that can become dangerous very quickly. My resume includes stints designing thermal imaging software to control glass plants, implementing shutdown and notification controls for power generation plants and writing automation control logic for drywall plants. There are a bunch of opportunities for people to get hurt or killed in places like this. The people who build and manage these places require that the architecture of such systems be performed by engineers because of the legal jeopardy that would exist if they didn't have such requirements. This legal jeopardy extends into plant control and automation and employers in these areas insist that workers be certified professional engineers, too.
If those places are relying on software to keep people from getting killed you should assume they are already dead.
The Therac-25 case study (linked elsewhere in these threads) is an excellent study on why fail-safes should be mechanical in nature and based on well-known physical processes that have very few, well-studied states. Software has an effectively uncountable number of states; there is no way to guarantee that a complex software system won't fail at a critical moment due to it being in an unexpected, untested state.
There are ways to model software to prove the absence of certain bad behaviors - TLA+, proof languages, and whatever software was used to validate seL4 come to mind - but they are impractical to use on large systems.
France also has rules regarding who can call themselves an engineer, although software engineering is recognized. A "diplôme d'ingénieur" can only be delivered by accredited institutions regulated by the "Commission des titres d'ingénieur" (committee of engineering titles).
Whether or not an engineering school is accredited can be an important factor in deciding whether to join it after high school. Some software engineering schools that focus more on coding and tech skills without necessarily spending much time on other topics that provide a solid engineering foundation are not accredited. They are often seen as offering a degree that is less valuable than accredited institutions.
> On the contrary, there are many different types of engineers. Courts have long recognized that the term “engineer” has a generic meaning separate from “professional engineer,” and that the term has enjoyed “widespread usage in job titles in our society to describe positions which require no professional training.” […] “Engineer is synonymous with such terms as conductor, driver, handler, operator, and pilot.”
Canadian developer here. I always correct people when they call a developer a software engineer for specifically this reason. I've met exactly one person in my entire career that was actually a licensed engineer working in software. I always get the glazed over eyes look when I tell people that it is actually illegal to claim you are an engineer when you aren't because it's a regulated professional term, but I do it anyway because I think it's important. My father is a licensed mechanical engineer and he's allowed me to be on the periphery of his work, so I have second hand knowledge of how "loaded" the title is and why it is regulated to this degree.
The distinction is a good one, but the word "engineer" has a long history and varied uses. The guy who runs a train is an "engineer", is he licensed? (maybe he is).
It would be better to create a specific term, like "registered professional engineer (RPE)" that is unique, rather than trying to limit the usage of a common word. This is what I think most places do.
There is a term, it's "Professional Engineer" or P. Eng. Someone who is a "locomotive engineer" must also be licensed but I think the exception in terms of vocabulary is historical rather than practical.
The word may be "common" but it is also regulated and defined in law.
I think that the term software engineering is helpful in distinguish between building complex systems composed of many software entities versus writing code for a single application. I totally acknowledge that within-application structure can be both complex and sophisticated: I suggest that people writing such applications call themselves software engineers and not "developers" or "programmers".
Seems like someone has actually managed to get sued for using "Software Engineer" on social media according to the page. IMO that is a little bit concerning isn't it?
Amazon calls the role "Software Development Engineer" here.
You can, but it requires passing their exams. Apparently, that section about misuse is a warning of sorts because the title is very generic in the industry, and employees will be inclined to use it because everyone does so everywhere else.
Lots of "professional" cartels in Canada are granted power. We still call our engineers in Canada software engineers. No one has expressed concern so far.
While I mostly agree with you, my Canadian Mechanical Engineer father will gladly express his concern.
I've never been able to use the phrase "software engineer", despite having 20+ years of software experience because I was raised to believe that Engineers have silver rings, engineering degrees and professional standing.
We let theology professors call themselves doctor. The definition of engineer is "a person who designs, builds, or maintains engines, machines, or public works." Are we arguing that software is not a machine or in the case of social media, a public work? Many machines and public works are privately owned at that. Further, there is regulation for software and engineers are held accountable to it.
A business can title a person as an engineer with limited complaints, a person cannot market themselves as an engineer.
Here in Texas, we had a licensure board for Software Engineering for a minute, though it was eventually killed by our Sunset Commission, because almost no one was interested in it (sadly).
Interesting. It does seem like software engineering fits the three required criteria in the definition provided. So it seems like it's possible for it to start being licensed at such. That's taking the article literally. The more cynical interpretation is that the definition they give is neither here nor there and what they are really saying is "we get to decide what is and is not an engineer".
Each province gets to do that by law. There’s absolutely no problem calling yourself a Software Engineer in Canada if you are a licensed engineer in the province in which you practice.
Possibly, but a bureaucratic organization in Canada would not be a proper place to determine qualifications for software engineering. They are constantly behind the times in terms of testing, latest technology, and best practices.
There's a reason all those software packages say they're provided as-is without warranty. Nobody will ever personally be liable for their software which is a fundamental requirement of most engineering disciplines.
And the public as well. If I hire a lawyer, I have a signal that they probably have (at least) a rudimentary understanding of law, and are licensed to practice law. If I see a medical doctor, I know they have a degree and are licensed to practice medicine. If these people wind up negligent or put people in harm, I know that they have the chance of losing their license to practice law or medicine.
If I need an engineer, I should have at least some assurance that they know what they are doing, and that they aren't going to act unethically or against my best interest. I should also have some assurance that the fact they hold a license, means that they (probably) haven't been negligent, or harmful with their practice.
Professionalization is part of it, but not the whole part. The main part was to manage the number of members. Also, this professionalization greatly decreases the propensity for bridges collapsing due to negligence/malpractice but does not completely prevent it. [miami pedestrian bridge, galloping gurtie, KC hyatt walkway, genoa viaduto].
In the mid 2000's community colleges in Ontario ran programs with diplomas in software engineering. By 2010 they had to change it to software development.
To balance a little bit the other comments where everyone is saying it has no actual implication:
My previous company (one of the GAFAM) had to change the title of everyone to Software Developer after years of arguing with the local engineering body.
And if you happened to leave "engineer" on your Linkedin profile, people from said body were actually regularly checking profiles and directly messaging us with threat of legal actions against us personally.
I have a MSc in CS, just not from Canada. The only way to be able to use that title, is to pay a membership fee to the association(? cartel?) of engineering.
Is a fee sufficient?
(If so, surprised the company didn't just pay it). I thought in addition to other things you need to put in some time supervised by a licensed engineer (kind of an apprentice).
Writing code has little science behind it. Mechanical engineers can base decisions on physics and knowledge of materials. Software engineers have no such base to stand on. For example you can get rid of all buffer overflows with a compiler flag, but it slows down the software a lot. When is it better to have the safety versus the speed? Is the software engineer the one who actually makes that decision? There is no standard formula you can use to decide that question. Before you can make programming an engineering discipline, there has to be some science behind it. Until then "best practices" is probably the best that can be done and that is just a checklist, not calculated engineering.
Another issue is domain knowledge. A programmer can write code for any application, medical, automotive, chemical plant control, nuclear reactor control, aircraft flight control... What engineering principles of software design cover all of those? Certainly there would be some, but each domain has it's own criticalities and requires special knowledge. Instead of teaching beginners to write code it may be necessary to teach them to write medical code, automotive code, etc., or else they would learn the wrong lessons and have to unlearn them later. That specialized training might help turn software development into an engineering discipline, but it would also divide the field into specializations making it much more difficult to find and train people and make it more difficult for programmers to switch fields. The number of specialized types of programmers is huge, everything today is computerized. Maybe the creation of special libraries for each kind of code would bring some standards and uniformity? For example, requiring that you can only write medical code using one of a few approved HL7 libraries, or one of a few medical image processing libraries that are freely available to all companies. Standards and approved libraries might be one way to start turning programming into engineering. It would slow down innovation, but maybe that's a good thing since today a lot of "innovation" is more like customer lock-in.
Liability for flaws in code is another open-ended issue given there is absolutely no way to assure there are no flaws in code under all possible circumstances. You can write some math that says a bridge will support a weight load for 50 years if built of the correct materials. You can not do the same for code. Even the tools programmers use mutate over time. Compilers can have bugs. How do you certify a compiler for medical, space, automotive, and all the other applications it might be used for? What about open source software, who is liable for that? There is no such thing as an open source bridge or skyscraper design.
Uh oh, I just told my urologist I was a Software Engineer. From my experience over the last 15 years, no one cares. I'm sure it matters to the courts, though.
To become an engineer in Canada, you need to learn and commit to understanding in full every major engineering disaster in the country in the last 100 years, and how a failure in your duty as an engineer can actually kill people.
I feel like we could split software engineering from software development and gain a lot in our industry. Not all development needs to be engineering, but some absolutely does.