Looks like he ordered trains that were too tall, risking issues with tunnels, turn engineering, derailment, etc, and got caught by people who actually did know the engineering and science involved. Some things require credentials because it's evidence that the person knows what questions to ask, what to look for, and how to plan within the constraints of their domain of expertise.
This guy could probably do a great job supporting a person or team that had the right training, but his ignorance was risky, regardless of his intentions.
I've seen the flip side, too, where PhDs have given awful people license to behave badly, inflicting their "expertise" on people as if it made up for the lack of diligence and follow-through, leaving destroyed companies and people in their wake.
Gotta have the work ethic and the training - the institutions behind formal engineering disciplines do a great job of ensuring they qualify the people who will put in the work and know what they're doing.
Asking "will these trains actually work on our infrastructure?" is a pretty obvious question to ask, not requiring any great in-depth engineering education or insight. This is also the sort of question a chief engineer can just delegate to an underling to research. It's of course easy for me to say that in hindsight, but you really do need to be beyond clueless to never even consider it. I just did high school, don't know much about trains, and I'm reasonably sure I would checked. I might have been found out in some other way, but not through this.
Seems more of a good old-fashioned corruption case. And oh yes, by the way, he also faked his PhD.
Credentials are one of those things that amplify social effect. A good person with credentials can do more good more easily. An idiot, dishonest person, or delusional ideologue with credentials can do a lot of harm.
A good example of the latter effect is that thoroughly debunked autism/vaccine paper from a while back that has probably cost thousands of lives at a minimum.
He claimed to be an engineer, which is a profession with real formal qualifications, because there are real consequences (e.g. buildings falling down, bridges collapsing, people dying.)
The case is also linked to the larger system of patronage and state capture that existed under Zuma, where if you paid the right people who back then were in the ANC, plenty of doors would open up.
Cyril Ramaphosa began a cleanup of the ANC, but it's still a work in progress AND Zuma and his patronage network have created their own party that is undercutting the ANC's vote share (at least the private sector forced the ANC-DA-IFP coalition).
It's a stunning reversal for a country that 15 years ago was on track to become a developed country.
South Africa in the late 2000s to 2011 was at the same distance from becoming a World Bank High Income country that Serbia and China are at today in the late 2010s and early 2020s, and South African companies like Naspers (Reddit, Tencent, VK, StackOverflow, Udemy, OLX), MTN Group (major telco player in MENA), ShopRite (major retailer across Africa which is basically a Walmart or Lidl-lite), and Vodacom (major telco and formerly satellite player in MENA and Asia) were on track to becoming major players globally.
There are many here that do the same: Many IT jobs have titles with engineer (and architect, int al) in them. Those "engineers" are not chartered in the formal sense. The term engineer is somewhat watered down these days, in a formal sense - it has become commonplace.
I studied as far as what can be described as a civil engineering technician. Not an engineer. I own an IT company with 30+ years time served at the ... keyboard and rack and rails. I've frozen my nuts off in ill advisedly cold computer rooms to rescue improbably important systems and so on.
Anyway, I allow some of my staff to call themselves technicians or techies, never engineers. I encourage the term "consultant" for time served staff.
Not true - professional engineering bodies in Canada are full of themselves and like to claim that though.
Professional Engineers Ontario for example claims here that:
> The term Engineer/Professional Engineer/P.Eng. can only be used by those that have been granted a licence by PEO, under the authority of the Professional Engineers Act. The title “Engineer” is restricted to Ontario licence holders under s. 40(2)(a.1) of the Act.
Which is a very disingenuous interpretation of that clause:
> (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;
And conveniently ignores the context of the previous clause to distinguish “engineer” and “professional engineer”
> (a) uses the title “professional engineer” or “ingénieur” or an abbreviation or variation thereof as an occupational or business designation;
The common perception is something along the lines of "In Canada, it's illegal to call yourself an engineer unless you have a PE license, full stop." The quote from Professional Engineers Ontario seems to encourage this interpretation. But the statute they cite seems to be more specific than that.
Offence, use of term “professional engineer”, etc.
(2) 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;
[...]
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.
I believe the hierarchy used here is meaningful. The use of "engineer" (as opposed to "professional engineer") is addressed in subparagraph (2)(a.1), under the paragraph (2)(a), which says that your job title or business name can't be "professional engineer" unless you are a professional engineer.
Paragraph (2)(a.1) extends this to say that your job title or business name can't use "engineer" in a way that will make people think you are a professional engineer when you really aren't. This is in the context of the parent paragraph about claiming to be a professional engineer. If it were prohibited wholesale to call yourself an "engineer" under any circumstances without holding a PE, I wouldn't expect that to appear in this form in the statutes.
In short, what the law really seems to say is that, without a PE license:
- You can't claim to be a Professional Engineer
- You can't claim to be an "engineer" and let people think it means you're a Professional Engineer
This focuses on making sure that when we rely on engineering plans, they have been examined and approved by someone who knows what they're doing -- not on making "engineer" a protected title that is illegal to use unless you have a license. This interpretation of the statute suggests that there is actually nothing illegal about the use of the word "engineer" in job titles in Canada, as long as it's not done in a way that would cause a reasonable person to believe it means "licensed professional engineer".
It says or abbreviation which I imagine would cover engineer. It's well established here that you call yourself doctor or use the Dr abbreviation either if are not an active member of the college of medicine.
I am somewhat familiar with all these rules since a trained engineer with a PhD, but I am not a active member of the professional engineer association. I also used be a have the work title of "principal architect". In reality I can't legally call myself (or really let others) doctor, engineer or architect. I must admit it's a bit challenging when dealing with multinational.
Yes, the term in question for me is only "engineer".
> (a) uses the title “professional engineer” or “ingénieur” or an abbreviation or variation thereof as an occupational or business designation;
So (a) tells us rather clearly that we can't present ourselves as John Doe, Professional Engineer, or call our business a Professional Engineering firm, or whatever.
> (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;
Here, (a.1) seems to add, specifically as a sub-paragraph to (a), that it's also prohibited to call yourself an "engineer", or "eng.", etc., if it will make people think you're a professional engineer.
According to Reading Law: The Interpretation of Legal Texts (1), one of the canons of interpretation is that "Material within an indented subpart relates only to that subpart".
While (a.1) is not indented with whitespace (2), I believe the paragraph numbering is functionally equivalent.
Further, the Fundamental Principle #4, "Presumption Against Ineffectiveness" is of some interest: "A textually permissible interpretation that furthers rather than obstructs the document’s purpose should be favored". Of course, it would not obstruct the purpose of the statute to interpret it as prohibiting whatsoever the use of the title "engineer". I bring up this principle because it implies that purpose is relevant to interpretation. That's why I think it's significant that the overall purpose of this statute is apparently to prevent people from being mistaken about who is and isn't a licensed professional engineer.
So, if we take for example the matter of people calling themselves "software engineers": The phrase "professional engineer" or equivalent wasn't used, which would have been prohibited outright per (a). Now, for (a.1), is this use of the word "engineer" going to make a reasonable person believe that the SWE is a professional engineer who can sign off on plans of the sort that require licensure because people die if the plans are wrong? I don't think so, and as far as I can see, it is only in those circumstances that "engineer" by itself is a protected title. I suspect what happened is that people/companies largely opted to avoid trouble by avoiding the word entirely, leading to a common assumption that "engineer" per se is entirely off-limits unless you're a PE.
In that case he is not acting as a chief engineer,rather as a procurement or purchaser. Chief engineer is not a role where you can simply pass on engineering responsibility to third party.
In contexts where "engineer" is a licensed title like "doctor of medicine" and "attorney at law", sure.
But the point of credentials like these is not only that they're shorthand for a range of requirements (degree granted by appropriately accredited institution, passed licensing exam, insured, practice complies with relevant professional standards, etc.), but also that they're issued by organizations that have mechanisms in place to verify that a particular applicant actually possesses the credential in question, e.g.,
Hence why throwing around the term "engineer" in software is silly. There's little consequence to misrepresenting yourself in software, other than your immediate employment and maybe a financial lawsuit. In other professions, enforcement has real teeth due to the stakes of failure.
Software failure might have increasing stakes these days. The CrowdStrike outage probably had more casualties than THERAC-25. Hospital systems shut down, people couldn't access secure areas with their ID badges, and 911 systems stopped working.
The thing is, you can hold an engineer that designed a bridge accountable for designing a poor bridge that failed under load. The strength of materials, the load bearing ratings of a particular design for a bridge, can all be calculated and are well known. How do you come up with the same types of calculations for software? You really can't, because writing software is more about designing a solution to problems people aren't already solving. You can write tests for the problems that you are skilled enough to anticipate, or even tests to cover problems you discovered in hindsight of a regression, and sure you can hold software engineers accountable for choosing to bypass the tests they write. But how do you hold a software engineer accountable for a failure mode that nobody considered already? It's like holding the very first person to design a bridge accountable for making a bad bridge, let's see you make a better one.
For that reason, I don't think we'll see software engineers accepting the same level of responsibility for their errors as structural engineers.
I can certainly see that there are some fundamental issues with assigning software engineers the level of responsibility that structural engineers have.
That said, from what I've heard, crowdstrike seems like a great example of something a hypothetical licensed software engineer should lose their license for. I admit I don't know all the details, but it seems that an update was pushed to prod that immediately broke all windows machines. Doesn't that mean they pushed an update to customers without testing it even a single time, on a single windows machine? I heard they even bypassed customer staging environments?
I also find it interesting to consider what the future holds. A few possible paths seem like:
1) The state of the profession progresses to the point where we have enough widely recognized best practices to make licensure meaningful
2) We consider the benefits of rapid, cheap(er than the alternative), software production as being greater than the costs of crowdstrike level events, and change nothing
3) We adapt software system architectures on the customer side so that there's meaningful oversight and accountability inside an organization (in many ways enabling #1)
There was a very very extensive write-up from crowdstrike about what went wrong including how tests were passed if you are interested but I want to comment on your hypothetical series of events.
None of that responsibility falls under software "engineering" specifically but actually under the broader scope of systems engineering, the problems you stated is about how different systems interacted in a failure case, not about how any individual system that any individual "engineer" worked on failed.
Is it as much Microsoft's fault that repeated bluescreens from a failing kernel driver didn't prompt the OS to stop loading said driver and try to boot?
Is the the engineer that wrote the faulty code's fault? Their EM? The PM who approved bypassing staging? Who is the one who should be investigated and fired, what if there are 100 people that touched the codebase in the last "sprint"?
This leads to accountability and liability, who should be held liable, the is literally the point of chief engineer, he is held liable, financially if possible and criminally if proven. Who is the "chief engineer" in your #1 hypothetical for a company and what are their qualifications and skill level? That's the real question, because we know the standards are not there, if you go and read the crowdstrike report you will find it was an out of bound access, the index passed in from another system. It's not statically verifiable and bounds checking at runtime with a crash (ala rust) would have still caused the crash. The only way to do that would be to place a manual bounds check before the call site, which has been best practice for decades and yet still isn't happening, so its an accountability thing, someone did a code review, probably gave a LGTM because the array has bounds checking which would catch an out of bounds read but didn't concider the fact that it crashing would bring down the host.
> Is it as much Microsoft's fault that repeated bluescreens from a failing kernel driver didn't prompt the OS to stop loading said driver and try to boot?
Nit. Windows does have something that does this. Failing kernel drivers are excluded on reboot. But Crowdstike marked the Falcon(?) driver in some way that prevents booting without it, even in safe mode. After all, being able to force a boot without your antivirus system isn’t safe, so why allow it?
Countee nit. It is a WHQL approved driver. Microsoft validated it to do that.
It's all hypothetical regardless, the point is that there are so many people involved in that specific failure and if they really wanted to investigate it they will likely find some best practice was followed and the failure occurred anyway
"Real" engineers do new things too, where there may be un-anticipated failure modes, and where the answer can't just be looked up from a book of standards. Things like boring the world's longest tunnel under a mountain with sparsely available geological samples, building passenger trains that beat the world speed record, building reusable space rockets, and so on. Software engineers aren't the only ones solving novel and complex problems, and failure is sometimes understandable.
You don't lose your license if you fail at solving a hard problem, where nobody has succeeded before. But to be granted the responsibility to attempt those problems you have to demonstrate experience, education, and competence. You lose your license if you demonstrate disregard for ethics, basic safety standards, recordkeeping, and so on. I don't see why software engineering can't, in principle, have a similar level of professionalism, especially when critical systems are being built on top of it. But it would strongly conflict with the ethos of anarchy, moving-fast-and-breaking-things, and autodidact garage hacker culture that permeates the field (and which software engineering has greatly benefitted from).
In practice, engineers are not sent to jail only if the bridge they designed falls. They are sent to jail or punished otherwise if it is shown in a court or similar investigative process that they intentionally or unintentionally failed to follow standards or reasonable foreseeable precautions.
The same can very easily and must exist for software engineers. Some body comes up with a set of safety and security standards, and all the licensed engineers ensure the software under their wing conforms to those standards.
Software engineers will accept this responsibility when eventually governments pass laws regarding this, as they have done for other professions. It just takes time.
Software is simply too complex. The complexity is mitigated with abstraction, but the abstracted code quickly becomes complex again, and it once again gets abstracted.
Layer this a bunch of times and you get to where the regular SWE is working.
However, that doesn't mean we cannot have bug-free code. It just means that code would have to be written close to hardware, likely by a team fluent in both hardware execution and software architecture.
Using phased rollouts of updates has been a thing for well over a decade at this point. Microsoft uses phased rollouts for windows updates. Google does the same for chrome. To say nothing of proper testing and fuzzing.
It’s not a mystery why crowdstrike brought down so many companies and got people killed. Their engineering practices were foreseeable bad and people died as a result. Wah wah software is complicated. So what? That’s why you learn to do it properly before you install your software in hospitals and airports.
Learn to take responsible for the outcome of your work. Software is complex, yes. Keeping that complexity in check is what software engineers are trained for and hired for.
I _think_ I'd like to see software development get some sort of accreditation because... man, there are a lot of people doing it who shouldn't be doing it. But I wonder if that would really do much beyond requiring everybody who worked as a programmer to pay some annual fee and fill out some extra documentation every time they made a change.
NCEES attempted to create an accreditation scheme in the US for Software Engineering, but canceled it because few people took the exam [0].
It's not surprising that almost no one took the exam. It wasn't well publicized and employers do not require an FE or PE for software engineers. You also have to pass the FE. The closest relevant prerequisite was the FE in Electrical and Computer Engineering, which most CS coursework would not cover. And you need to spend 4 years working under a licensed PE. Ill-conceived and executed.
I certainly wouldn't, especially if it's going to be modeled on other accredited fields like Medicine and Engineering where you can't even see the review board until you've made it through formal education. Software development is one of the few places where someone like me, who is allergic to pedagogy, was able to find professional success not mired in stifling bureaucracy.
The overwhelming majority of software has absolutely zero criticality. The retail staff at your local supermarket can do more damage through negligence than virtually any given programmer. Fucking us over because of an incalculably tiny minority of jobs is a ludicrous proposition. No thanks.
Yeah, there are a lot of people who have no business making this field their profession. It's also a profession that's rather difficult to test for competency without filtering out 95%+ of the workforce. That's why it's important for leadership in charge of those roles to have deep domain knowledge to filter out people who aren't up for it. That's the entire point of an in-depth interview process.
Well, the CS program differs slightly between polytechnics and universities. The former emphasizes practical engineering, such as networking details, while the latter focuses more on theory, such as algorithm correctness proofs. I think our job requires a lot of engineering due to reliability, performance, compatibility, communicating design, etc.
To be honest, "engineers" in the physical sciences generally have a much easier and predictable time than programmers. Is that perhaps a fault of programmers, very possibly (nevermind, definitely our own doing). The reason I say they have an easier time is that a lot of their "problems" are solved, have general solutions and lookups, best practices that you can not deviate from, etc.
E.g. look at the amount of times we all have to re-invent distributed work queues and notifying other systems of something. If we were in the context of physical engineering, there would be maybe 4 options, all with well-understood pros/cons and you just pick the one that fits your performance profile and requirements. Done. And then sure, we could get some "certified engineer" software title where a person can confidently say "yes I sign off that if you use this option, and your estimated load of messages per second never exceeds Y, and you have provisioned X-units of compute on your server, then you will lose less than 0.01% of messages." What an easy job that would be - Except we have countless hipster-devs all wanting to "do it their own way" and write their own library for it.
You used message queues which is a hard problem and compared it to what is probably a simple problem in engineering, picking a material or screw size or such.
You have disciplines in software that can easily be equated to the engineering you described, many people get paid a lot of money to create CRUD apps. Which database do you select, how do you implement the webserver, do you seperate out the API and frontend? these are all pretty easy problems to solve and have solutions with obvious pros and cons, sure you can have someone try some novel technique every now and then but the industry as a whole know how to do that.
When you start discussing distributed systems it's kind of in autonomous Mars rover territory, the best practices are kind of there but there isn't a ton of consensus that what is known is even the best solution.
Not really because much of the older hardware was replaced by software. See PTOs. Current hardware increasingly relies on embedded software. We are using it for payments, driving our vehicles, coordinating railway traffic, flying planes, calculating bridges.
Railway engineering... 15 years career, which tells quite a lot about a lot of things, generally nothing good. Best aspect is it doesn't seem anyone got physically hurt in "the process of career progression". Quite scary.
"Engineer" in the software world is just a job title like calling yourself a "scrum ninja". It's not a protected title like "professional engineer" in the US or the equivalent in SA. The bar for the former is "I like it", the bar for the latter is usually set by law.
Lying about your software engineering chops might get you fired, maybe even on the hook in a civil lawsuit. Lying about being a professional engineer while practicing engineering is usually a criminal matter.
So I can't imagine lying about your software engineering chops landing you in prison even if we're talking about critical sectors like medical or aerospace.
>"Engineer" in the software world is just a job title like calling yourself a "scrum ninja". It's not a protected title like "professional engineer" in the US
getting an engineering degree from a university requires you to study a lot of the same higher mathematics regardless of specific field, and entitles you to call yourself an engineer, even in CS.
the "professional engineer" certification is a bit more vocational, indicates you've passed qualifying exams based less on intense math and more on your knowing standards for specific govt building codes, etc.
The core of classic engineering is learning how to work with Mother Nature OS. In software engineering you almost never have to deal with that absolute gut punch of an OS (usually at worst you just have to deal with the humans who are a product of it), and don't need to take classes to learn about it.
To be a professional engineer, or just engineer really, you need to maintain your license, be in good standing with the regulatory bodyz have professional insurance, etc. The regulatory body can impose fine, mandatory training or disbar you for any ethical or technical deficiency. It's not a one time certification as you seem to believe.
I am not aware of the US having any laws on who can call themselves Engineer or not - it's not like Canada. Having a printer and a sheet of business card blanks entitles me to call myself an engineer.
That press release seems to be specifically about their failure to get him to stop using the term “engineer,” and the fact that the legal system recognizes a difference between it and the more protected term “professional engineer.”
> laws on who can call themselves Engineer or not - it's not like Canada
It is like Canada in practice, depends on the terminolgoy they use. The two world's of "engineering" are so separated from each other, that's why I wrote a comment and that's why you are unaware of the distinction.
You have skyscrapers in Canada, oui? If you want to change something structural on the facade (O, Canada, I mean façade) near the top of a skyscraper, like put in a balcony/observation deck, they are not going to let you do that till your plans are reviewed by a licensed engineer. Not any old engineer, only by somebody Licensed to review plans like that, who will take into account everything that needs to be taken into account, like crap falling on pedestrians walking below, 30 years from now when the concrete is starting to disintegrate.
That is a licensed engineer. Canada has them. You don't know about them because you don't own a skyscraper. I know about them because I was on my condo board... in a skyscraper. they do structural, electrical, HVAC, plumbing, etc.
The school I went to was 80% mechanical engineers. Had they offered computer engineering, as compared to computer science, my degree would have had more overlap with physical science than virtual science (of computer engineering).
It’s just not a practical degree in the US. You don’t need thermodynamics, statics, and a bunch of other physical engineering requirements to build software.
Despite being called an "engineer" a lot in recent years, it always feels icky because of what you just said here about it being a protected title in other industries. Not quite imposter syndrome - just feels like the wrong word for our job. It at least leaves out the linguistic/creative aspect of programming, and the execution/quality aspect of putting it all together.
It's more like digital construction: Programming is more like the construction project, and less like the AutoCAD "design" piece that engineers work on. The AutoCAD piece has more in common with product design than programming.
If anything, designers should be "engineers" and "eng. directors", and programmers should be "technicians" and "technical directors". They engineer products, with deliverables being design documents. And the techs implement it with the deliverable being the technology itself.
I use the title because it's what the piece of paper my university gave me when I graduated says. "Programming" is a portion of my job, alongside reviewing other people's work, design, and sitting around in meetings with people who don't have technical knowledge. Any mechanical, electrical, civil, etc, engineer will have a similar experience in many cases, except replace "programming" with something related to their area
professional engineer license is required in addition to graduating and other prerequisites to be called "professional engineer" tho, no? school alone is not enough to be designated a "professional engineer", right?
Indeed. Programming is just a translation step. If you have done your information system design properly, it will have undergone several phases of stepwise refinement from requirements to code, with documents and flowcharts explaining the logic.
Sadly, programmers have been doing too much of the design work in recent decades, and the result has been akin to "the inmates running the asylum".
I completely agree, but we need some kind of title to differentiate the people who are as versed in CS and pragmatic programming - from the lowest asm/C to Lisps and MLs - and the typical JavaScript dev who did a web course.
At least here, both are called (software) developers and I really don't want to be painted with the same brush as web cowboys who don't value stability and things done "properly".
given the demographics here, i can imagine for many of us the first impression was "someone lying on their cv for a tech job got caught".
but "real" engineering (as my core engineer professors used to snark at us) has real-life consequence and many countries have laws for holding their work accountable. this is just an example of that but to save face, they are focusing on their credentials in this case.
as an "engineer" in tech myself, i really feel that our industry misappropriates a lot of these terms, at least for job titles. i am all for naming consistently this way, but we need to also treat what we do in the same lens then. like the recent crowdstrike incident would have also resulted in jailing someone, but not sure if we need to be that serious about it.
> The thirteen Afro 4000 diesel locomotives that have so far been delivered to Prasa are worth R600 million and form part of a larger R3.5 billion order for 70 new locomotives.
Interesting. In the Netherlands our prime minister candidate was killed a while ago. Killer was on the street within ten years. Imagine that? Someone killing Kamala Harris and being allowed on the street again after ten years?
An engineering mistake here could become a huge derailment resulting in loss of hundreds of lives. A 15 year sentence is quite lenient in fact if you think about it.
> Killer was on the street within ten years. Imagine that?
Progressive European policies I guess. We'll see Anders Brevik roam free shortly. Maybe he could than meet Volkert van de Graaf and have a chat about their favourite subjects.
True, I myself could whip up a a dozen fake CVs/resumes right now with no jail risk whatsoever, the real crime is fraud and the CV was just an implementation detail.
This guy could probably do a great job supporting a person or team that had the right training, but his ignorance was risky, regardless of his intentions.
I've seen the flip side, too, where PhDs have given awful people license to behave badly, inflicting their "expertise" on people as if it made up for the lack of diligence and follow-through, leaving destroyed companies and people in their wake.
Gotta have the work ethic and the training - the institutions behind formal engineering disciplines do a great job of ensuring they qualify the people who will put in the work and know what they're doing.