No other profession trivialises their profession to the degree of software(ghuntley.com)
ghuntley.com
No other profession trivialises their profession to the degree of software
https://ghuntley.com/squirrel-burgers/
205 comments
For sure. The problem isn't the people, though they definitely can be part of it, the problem is the process.
We never get a chance to reflect critically on our product. Imagine if an architect always would have their first draft constructed, without consulting a structural engineer, or the municipality or even the clients. They can't because if they did their company would either run out of money while they are at the drafting table, or a different company will build another shoddy but functional building faster and outpace them.
This is how software gets made, not necessarily by unqualified engineers, after my degree and 15 years of professional experience I feel my first draft on a software project has a reasonable chance of standing up in the high winds. But hasty and incomplete processes.
Agile like processes are an improvement, at least there is allotted time for improvements and corrections while the apartment building is still 1 story before and the customer can at least walk around a fully furnished apartment before we slam the other 99 on top.
We never get the chance to have our code audited when it is done, but before it is pushed to production. Best we can do is have a test suite with good statement coverage.
That being said, if we improved this situation software would be only marginally better. As awful as some of these problems are, they can slumber in software for decades before causing any harm, and frankly the amount of harm is quite limited.
We never get a chance to reflect critically on our product. Imagine if an architect always would have their first draft constructed, without consulting a structural engineer, or the municipality or even the clients. They can't because if they did their company would either run out of money while they are at the drafting table, or a different company will build another shoddy but functional building faster and outpace them.
This is how software gets made, not necessarily by unqualified engineers, after my degree and 15 years of professional experience I feel my first draft on a software project has a reasonable chance of standing up in the high winds. But hasty and incomplete processes.
Agile like processes are an improvement, at least there is allotted time for improvements and corrections while the apartment building is still 1 story before and the customer can at least walk around a fully furnished apartment before we slam the other 99 on top.
We never get the chance to have our code audited when it is done, but before it is pushed to production. Best we can do is have a test suite with good statement coverage.
That being said, if we improved this situation software would be only marginally better. As awful as some of these problems are, they can slumber in software for decades before causing any harm, and frankly the amount of harm is quite limited.
> We never get a chance to reflect critically on our product.
Much of the Internet is built on publically available code, so anyone absolutely has the chance to critically review those projects and products. It's not clear how more gatekeeping would be an improvement; in fact, it would most likely make things worse.
Much of the Internet is built on publically available code, so anyone absolutely has the chance to critically review those projects and products. It's not clear how more gatekeeping would be an improvement; in fact, it would most likely make things worse.
> Much of the Internet is built on publically available code, so anyone absolutely has the chance to critically review those projects and products.
Sure:
- "Search for thing that do X"
- "npm install thing"
- "drinking cofee while it install 1000 deps"
- "it works"
- "end of critically thinking about this".
Sure:
- "Search for thing that do X"
- "npm install thing"
- "drinking cofee while it install 1000 deps"
- "it works"
- "end of critically thinking about this".
I meant we don't get a chance to spend time on reflecting critically. What I was thinking of specifically is how many people that depend on Log4j have actually read the Log4j source code and reflected on whether its complexity was a security risk to their product.
How many people could go "Hey boss, we're gonna take 2 developers and spend the next two sprints moving our code base away from the industry standard logging framework because it has too many features".
How many people could go "Hey boss, we're gonna take 2 developers and spend the next two sprints moving our code base away from the industry standard logging framework because it has too many features".
Why do you assume he's talking about colleges? This brings in a whole tangent about PhDs. CS PhDs shouldn't be expected to be software craftsmen any more than physicists should be expected to be extremely good carpenters. There's a little overlap in the skill-sets, but not much...
And in addition, you can be a master-coder but still suck at building products that solve your customer's problems.
No, no. A better comparison is like asking a physicist to be an engineer, and they should be reasonably good at that, though are usually lacking breadth of field. A CS PhD only reasons about things you can conceivably do on a computer, so being confused by a computer is a bad sign.
I disagree, for multiple reasons.
You can see the examples that were brought up here. Function name lengths, log4j, dealing complex systems. The first two definitely have nothing to do with CS, the last could be I guess, depending on the overall architecture, but lots of complex systems are just piles and piles of simple cruft. That's not a CS problem.
I don't think engineering is the right analogy here. A better one would be: Physicists exist, so do electrical engineers, and so do electricians. Physicists do discovery, electrical engineers do design, and electricians do implementation. And unsurprisingly, the electricians are the most likely of the three to require a license to do their work. Most programmers do implementation work.
Finally... No, I don't think a physicist would be a good engineer necessarily, particularly in this context. I mean, there exist branches of engineering that are more like physics -- yes, a physicist should be able to turn into an antennas guy, I guess. But I don't see why a physicist would be good at making designs out of digital building-blocks.
You can see the examples that were brought up here. Function name lengths, log4j, dealing complex systems. The first two definitely have nothing to do with CS, the last could be I guess, depending on the overall architecture, but lots of complex systems are just piles and piles of simple cruft. That's not a CS problem.
I don't think engineering is the right analogy here. A better one would be: Physicists exist, so do electrical engineers, and so do electricians. Physicists do discovery, electrical engineers do design, and electricians do implementation. And unsurprisingly, the electricians are the most likely of the three to require a license to do their work. Most programmers do implementation work.
Finally... No, I don't think a physicist would be a good engineer necessarily, particularly in this context. I mean, there exist branches of engineering that are more like physics -- yes, a physicist should be able to turn into an antennas guy, I guess. But I don't see why a physicist would be good at making designs out of digital building-blocks.
I'm not sure you're qualified to be commenting on this. Physicists, electrical engineers, and electricians all do discovery, but not all of them, and when they do, in different capacities.
There's definitely a lot of ways that physicists and scientists in general don't make good engineers. But a physicist has a good shot at being a reasonable engineer, after getting over the fact that they don't actually know everything and rules of thumb and physical models have to be created taking into account the complex emergent behavior we see in reality.
Same thing for CS PhDs and software engineering. They should be set up to undertake these things well. Not being able to do so is a mark against them. They don't immediately understand the complex emergent behavior of modern computer systems but neither has any SWE.
There's definitely a lot of ways that physicists and scientists in general don't make good engineers. But a physicist has a good shot at being a reasonable engineer, after getting over the fact that they don't actually know everything and rules of thumb and physical models have to be created taking into account the complex emergent behavior we see in reality.
Same thing for CS PhDs and software engineering. They should be set up to undertake these things well. Not being able to do so is a mark against them. They don't immediately understand the complex emergent behavior of modern computer systems but neither has any SWE.
But all you’re saying boils down to the best practices being questionable, not that actually formalizing them into a proper craftsmanship wouldn’t make sense if we actually made better best practices.
You may talk about gatekeeping all day, but at the end of the day we do want the code in our pacemakers, cars and drones to be written by people following stringent standards, such that we have some idea of the quality.
The fact that said standards may not yet exist is not an argument against that, it’s an argument against the status quo in standards.
You may talk about gatekeeping all day, but at the end of the day we do want the code in our pacemakers, cars and drones to be written by people following stringent standards, such that we have some idea of the quality.
The fact that said standards may not yet exist is not an argument against that, it’s an argument against the status quo in standards.
The issue with standards is that they only capture a very, very small part of the problem.
Let‘s look at the results: NASA probably uses some of the most rigorous development and testing methods in the world, but I‘d still rather trust my life to the flight control software of SpaceX who doesn‘t give a damn about education.
The banks losing data mentioned by OP are way more rigid in their hiring and certification standards than a Stripe for example. Who would you rather trust on security?
My point is: I’m all for better code, but Culture trumps certification and standards every single time.
Let‘s look at the results: NASA probably uses some of the most rigorous development and testing methods in the world, but I‘d still rather trust my life to the flight control software of SpaceX who doesn‘t give a damn about education.
The banks losing data mentioned by OP are way more rigid in their hiring and certification standards than a Stripe for example. Who would you rather trust on security?
My point is: I’m all for better code, but Culture trumps certification and standards every single time.
> NASA probably uses some of the most rigorous development and testing methods in the world, but I‘d still rather trust my life to the flight control software of SpaceX who doesn‘t give a damn about education.
Why? Have there been any NASA manned accidents that were caused by software? There's certainly been big historical bloopers in the past involving unmanned probes, like getting metric and imperial mixed up, but doubtless NASA software quality is better now. And what is your basis that SpaceX doesn't care about education, while NASA does? Are you a hiring manager at either?
> The banks losing data mentioned by OP are way more rigid in their hiring and certification standards than a Stripe for example. Who would you rather trust on security?
Is that true that banks are more rigid in those standards? Or Stripe is more lax?
Why? Have there been any NASA manned accidents that were caused by software? There's certainly been big historical bloopers in the past involving unmanned probes, like getting metric and imperial mixed up, but doubtless NASA software quality is better now. And what is your basis that SpaceX doesn't care about education, while NASA does? Are you a hiring manager at either?
> The banks losing data mentioned by OP are way more rigid in their hiring and certification standards than a Stripe for example. Who would you rather trust on security?
Is that true that banks are more rigid in those standards? Or Stripe is more lax?
There are only three deadly incidents to choose from, thankfully, and it happens they were caused by other kinds of (presumably licensed) engineers. Software incidents include a flight computer failure during the landing of Apollo 11. Another incident caused reset of their navigation computer, requiring them to recalibrate it using a tangible sextant. If we go a little beyond literal NASA, it’s not hard to find computer failures. Aside from the infamous 737 Max, we have the loss of a B-2 on takeoff, which costs the same as a space shuttle. (Thankfully the pilots ejected.) Then the famous story of the Patriot missiles’ first deployment. If I actually Google this, will I find no more?
> Software incidents include a flight computer failure during the landing of Apollo 11.
How did flight computer fail during Apollo 11 landing? If you mean guidance computer and famous 1201 and 1202 errors, those were not failures, but were caused by hardware bug they left unsolved on purpose.
How did flight computer fail during Apollo 11 landing? If you mean guidance computer and famous 1201 and 1202 errors, those were not failures, but were caused by hardware bug they left unsolved on purpose.
If we're just talking about aerospace at this point, hasn't the F-35 flight software been notoriously buggy
That's your choice, but in a space mission or in a self-driving car I'd rather not be a casualty of move fast and break things.
> not that actually formalizing them into a proper craftsmanship wouldn’t make sense if we actually made better best practices.
This is the start of a bureaucracy that will grind progress to a halt. Because now instead of solving problems we get to create a commission who can appoint a club that have the right to appoint the master craftsmen who will be capable enough to formalize best practices.
If you think that's hyperbole on how this stuff works, it is not.
Furthermore, why would we assume people who enjoy debating best practices know actual master craftsmen?
> The fact that said standards may not yet exist is not an argument against that, it’s an argument against the status quo in standards.
The fact that said standards have been tried, and you don't know about them is a very strong argument against them.
This is the start of a bureaucracy that will grind progress to a halt. Because now instead of solving problems we get to create a commission who can appoint a club that have the right to appoint the master craftsmen who will be capable enough to formalize best practices.
If you think that's hyperbole on how this stuff works, it is not.
Furthermore, why would we assume people who enjoy debating best practices know actual master craftsmen?
> The fact that said standards may not yet exist is not an argument against that, it’s an argument against the status quo in standards.
The fact that said standards have been tried, and you don't know about them is a very strong argument against them.
> This is the start of a bureaucracy that will grind progress to a halt. Because now instead of solving problems we get to create a commission who can appoint a club that have the right to appoint the master craftsmen who will be capable enough to formalize best practices.
This bureaucracy already exists, across myriads of RFCs, language design committees, FOSS groups, GitHub issues, Gitter servers, listservs. This process already exists, it just bumbles along inconsistently from community to community, company to company, project to project. And perhaps it should, because no size fits all. But it does exist and any attempt at formalizing them would not cause the start of a bureaucracy to exist, because such bureaucracies are in abundance in software development already.
This bureaucracy already exists, across myriads of RFCs, language design committees, FOSS groups, GitHub issues, Gitter servers, listservs. This process already exists, it just bumbles along inconsistently from community to community, company to company, project to project. And perhaps it should, because no size fits all. But it does exist and any attempt at formalizing them would not cause the start of a bureaucracy to exist, because such bureaucracies are in abundance in software development already.
If you define a bureaucracy making best practices so broadly as to capture GitHub issues, then the term becomes meaningless.
The sense the OP is trying to argue for (rather unsuccessfully) is a government bureaucracy that forbids people from deviating from those best practices. This is "serious", you see, whereas a competitive market of ideas leading to the organic development of best practices (what we have now) is "trivial".
The problem with that idea is that although it pleases people who associate government control with seriousness, the evidence it actually leads to better outcomes is mixed at best, and negative at worst. Regulatory capture is a real problem in many industries, and the attempt to fix things with regulated "best practices" can often be short term hacks that also inconveniently render more robust long term fixes illegal (finance has a lot of problems like this).
In the software world you can look at things like MISRA-C or FIPS to get a taste of what everything would look like if we don't keep systematically pushing back against these misguided people.
The sense the OP is trying to argue for (rather unsuccessfully) is a government bureaucracy that forbids people from deviating from those best practices. This is "serious", you see, whereas a competitive market of ideas leading to the organic development of best practices (what we have now) is "trivial".
The problem with that idea is that although it pleases people who associate government control with seriousness, the evidence it actually leads to better outcomes is mixed at best, and negative at worst. Regulatory capture is a real problem in many industries, and the attempt to fix things with regulated "best practices" can often be short term hacks that also inconveniently render more robust long term fixes illegal (finance has a lot of problems like this).
In the software world you can look at things like MISRA-C or FIPS to get a taste of what everything would look like if we don't keep systematically pushing back against these misguided people.
I don’t think government control is necessary. Much of what the OP is talking about can be undertaken by industry standards, or just by enough software engineers and software firms agreeing upon it, whether through a body like an IEEE or unofficially like how Agile spread in popularity.
We agree then! But the article author disagrees:
"Software practitioners should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice software engineering."
The article very clearly argues for government control of who can be a programmer or not (who is doing the revoking, otherwise). That would be destructive, fatal to innovation and totally counterproductive.
"Software practitioners should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice software engineering."
The article very clearly argues for government control of who can be a programmer or not (who is doing the revoking, otherwise). That would be destructive, fatal to innovation and totally counterproductive.
Sure, though this discussion doesn't have to be limited to the OP's constraints.
> better best practices
Really? No, seriously, where will this end? Now we need better BEST practices?
I mean. This "best practices" wagon is just a nonsense. My impression is some people don't want the burden of thinking, so they want something to memorize. And blame when things go wrong - which they inevitably will, as in any and all "crafts" and "professions".
Engineering, medicine, etc, are all full of examples of failures. Is this evidence they should get rid of certifications and all bureaucracy? No.
Is software failures an evidence we should have more bureaucracy? No, it's evidence we need to think more and memorize less.
Really? No, seriously, where will this end? Now we need better BEST practices?
I mean. This "best practices" wagon is just a nonsense. My impression is some people don't want the burden of thinking, so they want something to memorize. And blame when things go wrong - which they inevitably will, as in any and all "crafts" and "professions".
Engineering, medicine, etc, are all full of examples of failures. Is this evidence they should get rid of certifications and all bureaucracy? No.
Is software failures an evidence we should have more bureaucracy? No, it's evidence we need to think more and memorize less.
Then perhaps the best practices shouldn't be rules for rote memorization, but better approaches towards thinking and reasoning about code. Maybe this field could use more discipline in how it approaches not just creating code but reading code. What is the use of thinking if it's not guided by methodology? Didn't many of us study computer science?
But in practice, "best practices" are always set by some sort of stagnant bureaucracy, often some sort of quasi-union organization that demands fees and spends all its time trying to keep newcomers out of the profession in order to protect the salaries of those already inside it. Worse still, it can lead to dysfunctional behavior industry-wide that has no competitive path to fixing it.
Look at what's happened to medicine. Huge numbers of people have had their confidence in doctors seriously damaged over the past 2 years because they keep saying things that are patently nonsense, like "oh your period vanished for 5 months immediately after taking a vaccine, it must be a coincidence" (this happened to a friend of ours). Why do they say these things, well, because if they go against the party line on vaccine injuries they can lose their license:
https://trialsitenews.com/doctors-sanctioned-for-speaking-ou...
That sort of action has nothing to do with best practices and everything to do with power structures. The software equivalent would be something like, "if you imply Java is not the best language to build enterprise software in, you could lose your license" or "if you write forum software that doesn't run every post through this officially approved AI for misinformation, you can lose your license". It doesn't look like bugs magically disappearing. I'd expect the rate of bugs to go up, actually, as standards ossified and became irrelevant (see: FIPS).
Look at what's happened to medicine. Huge numbers of people have had their confidence in doctors seriously damaged over the past 2 years because they keep saying things that are patently nonsense, like "oh your period vanished for 5 months immediately after taking a vaccine, it must be a coincidence" (this happened to a friend of ours). Why do they say these things, well, because if they go against the party line on vaccine injuries they can lose their license:
https://trialsitenews.com/doctors-sanctioned-for-speaking-ou...
That sort of action has nothing to do with best practices and everything to do with power structures. The software equivalent would be something like, "if you imply Java is not the best language to build enterprise software in, you could lose your license" or "if you write forum software that doesn't run every post through this officially approved AI for misinformation, you can lose your license". It doesn't look like bugs magically disappearing. I'd expect the rate of bugs to go up, actually, as standards ossified and became irrelevant (see: FIPS).
What stagnant bureaucracy instituted Agile across the industry, or mandated the widespread adoption of Node, or React, or any hot trending technology of the decade? Ad hoc best practices or chosen tools get picked up all the time without a power structure demanding it.
Maybe the compromise isn’t to institute formal licensing, but rather pay more attention to and give more support to industry bodies such as the ACM/IEEE.
Maybe the compromise isn’t to institute formal licensing, but rather pay more attention to and give more support to industry bodies such as the ACM/IEEE.
Programming science does not exist.
And yet, programming claims to be guided by computer science.
Computer science is only vaguely related to programming, in roughly the same way that the travelling salesman problem is related to actually travelling salesmen.
(I personally hold that there are only three CS courses relevant to daily programmer life: graph theory, complexity analysis and state machines. Everything else is at best situational.)
(I personally hold that there are only three CS courses relevant to daily programmer life: graph theory, complexity analysis and state machines. Everything else is at best situational.)
Universities claim programming is guided by computer science, because they love sticking the label "science" on non-scientific things.
The average working programmer probably doesn't care whether their work is considered a science or not. Certainly I feel like the ROI on reading CS papers in my own career has been quite low. They have a habit of sounding useful and impactful until you finish reading them and realize there's a pretty major catch. I have a degree named "computer science" but it's questionable whether it was really scientific, given that science is usually defined as a study of the natural world. There's nothing natural about computer programming, outside of perhaps complexity theory. You could argue that maybe at the edges deep learning is blurring into a study of naturalistic phenomena, but you have to be careful, otherwise you reclassify pure maths as a science and I think everyone agrees that it's a separate thing.
The average working programmer probably doesn't care whether their work is considered a science or not. Certainly I feel like the ROI on reading CS papers in my own career has been quite low. They have a habit of sounding useful and impactful until you finish reading them and realize there's a pretty major catch. I have a degree named "computer science" but it's questionable whether it was really scientific, given that science is usually defined as a study of the natural world. There's nothing natural about computer programming, outside of perhaps complexity theory. You could argue that maybe at the edges deep learning is blurring into a study of naturalistic phenomena, but you have to be careful, otherwise you reclassify pure maths as a science and I think everyone agrees that it's a separate thing.
Best practices come as an accepted way of doing things. It means not reinventing the wheel for every project.
Of course best practices can only work for problems that have already been solved. There are plenty of problems that need innovative thinking and unorthodox practices. The more brain power you can dedicate to solving those problems, the better.
Of course best practices can only work for problems that have already been solved. There are plenty of problems that need innovative thinking and unorthodox practices. The more brain power you can dedicate to solving those problems, the better.
I can't imagine any serious developer thinking a licensing program would improve outcomes. One reason this blog post is a bunch of images and analogies instead of a coherently constructed argument about how things would work in practice is because that couldn't hold up to scrutiny.
>I can't imagine any serious developer thinking a licensing program would improve outcomes.
The "serious" qualifier makes this a "no true Scotsman".
If a developer thinks that, then one can always say "he is not a serious developer".
The "serious" qualifier makes this a "no true Scotsman".
If a developer thinks that, then one can always say "he is not a serious developer".
Just because an argument contains a logical fallacy doesn't mean the entire argument is fallacious. Never mind that the GP probably had a definition in mind for the words "serious developer" there, making it not a "no true Scotsman" fallacy but just a badly worded argument.
The developer just needs to have good systems thinking. Anybody who disagrees with that is a goals thinker.
A particular case where I would disagree with you is security. There has to be someone who is responsible and liable for large data breaches, and the way things work more often than not at the moment is that no particular person feels responsible at any company, and everyone basically just hopes it will all work out. This is the exact equivalent of a licensed electrician needing to sign off on any electrical work.
An absence of ensured quality standards in the profession also doesn't mean that there is an absence of tests, these are moved to the individual company level instead, and, in our profession, often take weird turns like ritualized coding interviews.
On the point that no serious developer would think that this improves outcomes, I have to disappoint you, there are major companies like SAP with a culture of requiring masters degrees for almost all promotions.
An absence of ensured quality standards in the profession also doesn't mean that there is an absence of tests, these are moved to the individual company level instead, and, in our profession, often take weird turns like ritualized coding interviews.
On the point that no serious developer would think that this improves outcomes, I have to disappoint you, there are major companies like SAP with a culture of requiring masters degrees for almost all promotions.
My first response is that the CEO or CTO should be responsible for data breaches. Leadership should be sure to give engineering enough time and resources to secure their systems. If a system is insecure it's usually a management failure.
But in practice, I don't think that works either. We're building immensely complex systems across numerous layers each of which is the result of thousands of engineering hours. The costs to properly harden and secure most systems is not worth it. And even if you spend the effort to harden the system, it could still fall to a carefully crafted attack.
If you get attacked by a 0-day exploit from a malicious nation-state there's a level at which most companies would fail.
Security isn't some binary thing, it's an onion. And there's no meaningful conversation to be had about security without first taking your risk profile into consideration.
But in practice, I don't think that works either. We're building immensely complex systems across numerous layers each of which is the result of thousands of engineering hours. The costs to properly harden and secure most systems is not worth it. And even if you spend the effort to harden the system, it could still fall to a carefully crafted attack.
If you get attacked by a 0-day exploit from a malicious nation-state there's a level at which most companies would fail.
Security isn't some binary thing, it's an onion. And there's no meaningful conversation to be had about security without first taking your risk profile into consideration.
Security certainly is difficult, but the Equifax hack wasn't particularly complex, was it?
You can't define complex in a way clear enough to be useful. Maybe in your eyes it wasn't a "complex" hack, but what specifically distinguishes Equifax from nVidia or the other tech firms getting hacked right now? That you could write down, formalize, test in a court of law and which would last more than 6 months as an accepted definition? What about the China/Google hack in 2010? That was widely regarded as a groundbreaking attack by a nation state, but it started with an employee clicking a phishing link.
Suppose you did have somebody who was responsible, and liable, with veto power.
Nothing would get done.
Nothing would get done.
I would've thought said person should be also given the power to implement better processes, not just veto existing ones.
The CEO is in charge.
Do you have any links to such arguments and rebuttals to them? I dare say it's not obvious to everyone why a licensing program would not improve outcomes.
No, sorry. I've never seen any argument of the sort that describes some cause-and-effect relationship, like, developer licensing => downstream effects => outcome improvement achieved. It's not like I go looking for these, though.
Okay, but then can't you apply your logic to other licensed professions? Like, say, electricians? Are you against licensing in general? or is your position that software is somehow fundamentally different from all the other professions in those regards?
[deleted]
There are sound arguments against professional licensing, yes. You may not find them discussed on this forum much but the arguments for and against licensing stretch back hundreds of years.
A few arguments you could search for, if you want to dig deeper:
- Licensing is used to restrict entry into the profession to prop up wages, i.e. it often turns into a form of wage cartel. In extreme cases it can degrade into a pure cartel without any connection to actual professional practice; NY taxi medallions are an example of this in which the license is tradable and rentable, because buying one costs millions of dollars.
- The qualifications requirements are often either redundant (everyone was asking for them anyway) or obsolete (the industry has changed but everyone still has to pass these tests). Obsolete licensing rules are often impossible to get rid of because the people who put effort into passing them don't want to see their "investment" be invalidated.
Again using taxi licensing as an example, black cab drivers in London have to literally memorize the street map of central London such that they can recite a set of street directions from any arbitrarily chosen A to B, on demand, from memory. It's called The Knowledge and there are examiners who test this. Just last week a newly qualified cabby was telling me about this. He recounted on how his first day he discovered that the Knowledge was useless for actual navigation because you can't memorize traffic conditions. So now he uses Google Maps/Waze anyway, because it lets you see congestion. The Knowledge became largely irrelevant with the arrival of high quality GPS units, but it lives on decades later because the licensing bodies won't remove a rule that gives them power and cabbies aren't allowed to deviate from it/like the way it keeps out low cost competition.
- Licensing can be abused for political purposes. The threat of medical license revocation is routinely deployed to silence criticism of government policies on COVID or COVID vaccines.
- Licensing is often subtractive rather than additive. The licensed software developer's answer to writing engine control code safely without bugs is MISRA-C. This takes C and tries to make it safe by writing down lots of rules to follow which get steadily more restrictive with time (MISRA-C:2012 contains 143 rules and 16 directives). The unlicensed software developer's answer to writing safe embedded code is Rust - the rules would say you have to use MISRA-C, so there'd be no point trying to go beyond it. Moreover nobody would have developed Rust because the internal drive for self improvement would be gone. The sort of people who created Rust are not the sort of people who also enjoy political lobbying, and the sort of people who funded it would have lost their motivation if they could just say "we comply with all relevant regulations" and wash their hands of errors.
A few arguments you could search for, if you want to dig deeper:
- Licensing is used to restrict entry into the profession to prop up wages, i.e. it often turns into a form of wage cartel. In extreme cases it can degrade into a pure cartel without any connection to actual professional practice; NY taxi medallions are an example of this in which the license is tradable and rentable, because buying one costs millions of dollars.
- The qualifications requirements are often either redundant (everyone was asking for them anyway) or obsolete (the industry has changed but everyone still has to pass these tests). Obsolete licensing rules are often impossible to get rid of because the people who put effort into passing them don't want to see their "investment" be invalidated.
Again using taxi licensing as an example, black cab drivers in London have to literally memorize the street map of central London such that they can recite a set of street directions from any arbitrarily chosen A to B, on demand, from memory. It's called The Knowledge and there are examiners who test this. Just last week a newly qualified cabby was telling me about this. He recounted on how his first day he discovered that the Knowledge was useless for actual navigation because you can't memorize traffic conditions. So now he uses Google Maps/Waze anyway, because it lets you see congestion. The Knowledge became largely irrelevant with the arrival of high quality GPS units, but it lives on decades later because the licensing bodies won't remove a rule that gives them power and cabbies aren't allowed to deviate from it/like the way it keeps out low cost competition.
- Licensing can be abused for political purposes. The threat of medical license revocation is routinely deployed to silence criticism of government policies on COVID or COVID vaccines.
- Licensing is often subtractive rather than additive. The licensed software developer's answer to writing engine control code safely without bugs is MISRA-C. This takes C and tries to make it safe by writing down lots of rules to follow which get steadily more restrictive with time (MISRA-C:2012 contains 143 rules and 16 directives). The unlicensed software developer's answer to writing safe embedded code is Rust - the rules would say you have to use MISRA-C, so there'd be no point trying to go beyond it. Moreover nobody would have developed Rust because the internal drive for self improvement would be gone. The sort of people who created Rust are not the sort of people who also enjoy political lobbying, and the sort of people who funded it would have lost their motivation if they could just say "we comply with all relevant regulations" and wash their hands of errors.
I don't think the claim to be rebutted here was "there are no sound arguments against licensing". Nobody says licensing is pure goodness. Rather, people are claiming "there exist sound arguments in favor of licensing", and the parent was negating that claim (hence the "I've never seen any argument of the sort that describes some cause-and-effect relationship, like, developer licensing => downstream effects => outcome improvement achieved") with arguments that would seem to apply similarly to other licensed professions. So the question here was whether (and if so, why) the parent believed there don't exist any sound arguments in favor of licensing for other professions.
I think a lot of software developers like to think of themselves as skilled code surgeons who precisely cut away solutions to life or death problems. Truth be told though, most software that gets built isn't very important. No one is going to die if another WordPress site falls over or if a mobile app crashes when you put an emoji in the Name field. People should be licensed when their failures have a serious impact on other people's lives. Devs don't need to be licensed; most of our failures are annoying rather than dangerous. The majority of us are the crystal aura cleansers of the medical profession.
The weird thing is: Software devs kinda like to have it both ways.
When you ask them how critical the things are they are doing, they like to (as you phrased it) think of themselves as skilled code surgeons who precisely cut away solutions to life or death problems.
When you suggest to them stricter rules, guarantuees, checks and laws like you have them in civil engineering or electrical engineering they look at you in horror: "What, you mean I can't just carelessly try out a new framework on a project?"
Programming to me is a multiplier profession. Unless you code for yourself privately, your code is going to impact other people, organisations and the environment we all live in. This can be a good thing because by making the right choice we can really shave off collective years of the useless stuff humanity does. But we can of course do the polar opposite as well: waste everybodies time, leak private medical data, create algorithms that feed violent racist content to kids, make mistakes that endanger whole industries etc.
Simple preventable things like uninitialized variables still caused the dirty pipe vulnerability in the Linux kernel in 2020. The only thing that tends to give me a little hope is the traction Rust seems to be getting — at least we can stop doing the totally obvious and preventable mistakes and move on to unpredictable and unpreventable ones?
When you ask them how critical the things are they are doing, they like to (as you phrased it) think of themselves as skilled code surgeons who precisely cut away solutions to life or death problems.
When you suggest to them stricter rules, guarantuees, checks and laws like you have them in civil engineering or electrical engineering they look at you in horror: "What, you mean I can't just carelessly try out a new framework on a project?"
Programming to me is a multiplier profession. Unless you code for yourself privately, your code is going to impact other people, organisations and the environment we all live in. This can be a good thing because by making the right choice we can really shave off collective years of the useless stuff humanity does. But we can of course do the polar opposite as well: waste everybodies time, leak private medical data, create algorithms that feed violent racist content to kids, make mistakes that endanger whole industries etc.
Simple preventable things like uninitialized variables still caused the dirty pipe vulnerability in the Linux kernel in 2020. The only thing that tends to give me a little hope is the traction Rust seems to be getting — at least we can stop doing the totally obvious and preventable mistakes and move on to unpredictable and unpreventable ones?
It's not websites or apps going down that's the issue here. Security breaches can very much have real impact on people. For security issues at least, it doesn't really matter how silly or nonconsequential the use case of your software is. What matters is the data you hold, and how you take care of it. Your software could literally be a background service gathering user data, and it could still be devastating for a user if that data gets leaked, even if they didn't know about (and were otherwise unimpacted by) your software's existence (or lack thereof).
There are lots of software security certifications though, for individuals and businesses. I've work with an ISO27001 company a few times - it's the CSO's job to assure things are done securely rather than the individual devs. The same is true for most aspects of the software lifecycle - PMs, security, QA, etc do have certifications available. Devs are just the people who do the hands on work, not the ones who made sure it's done well.
In that model, who ensures the code is written without buffer overflows, undefined behavior, XSS/CSRF/etc. vulnerabilities, SQL injection vulnerabilities, etc.? You're suggesting code review by the security team is sufficient to ensure developers don't need to think about/understand potential vulnerabilities?
The devs are responsible for the code, but the CSO is accountable for it. So it's the CSOs job to make sure the devs do their work well because it's the CSOs neck on the line if it isn't. That should take the form of the CSO making sure there's a budget for training the devs, security certification for senior devs who'll writing important aspects of the app, code review by the CSO and security certified devs, hiring in third party auditors, and so on.
Hiring a dev who's "Secure Developer Certified" might be an option too, but there would still need to be all the above checks in place to make sure they're writing decent code, so looking for the certification at the point of hiring is a bit redundant.
Hiring a dev who's "Secure Developer Certified" might be an option too, but there would still need to be all the above checks in place to make sure they're writing decent code, so looking for the certification at the point of hiring is a bit redundant.
Meanwhile, plenty of classical regulated fields have failures that kill people daily, regardless of regulation. Just open the newspaper for crashing airplanes, derailing trains, combusting cars, collapsing buildings and bridges, just to name the most spectacular ones.
Why would you leave bugs in the code? Why would you treat your software as unimportant? It's about self respect and recognition by others when you produce quality code, and undermining your efforts makes us stray from our Bell Labs predecessors.
Why would you leave bugs in the code?
The reason is simple - there isn't enough time in the day to both push out the required features and fix all the bugs. We prioritize features because that's what we believe increases our value. Whether or not that's actually true is a matter of opinion.
Our predecessors were expected to write code more slowly. They could take a year to make a small business app that a dev is expected to push out in 4 weeks now. And all credit to today's devs, we hit those deadlines. We achieve amazing things in very little time. But in our push to be as productive as possible we have largely forgotten that the most fundamental skill in software development - thinking about how to solve a problem well - hasn't changed at all.
We believe that using a new framework, or buying a faster computer, or typing on a different keyboard, will make us faster, more productive developers, and in our effort to compress the amount of time it takes to build something we have also compressed the amount of time we spend thinking about it. That's why we leave bugs in code.
The reason is simple - there isn't enough time in the day to both push out the required features and fix all the bugs. We prioritize features because that's what we believe increases our value. Whether or not that's actually true is a matter of opinion.
Our predecessors were expected to write code more slowly. They could take a year to make a small business app that a dev is expected to push out in 4 weeks now. And all credit to today's devs, we hit those deadlines. We achieve amazing things in very little time. But in our push to be as productive as possible we have largely forgotten that the most fundamental skill in software development - thinking about how to solve a problem well - hasn't changed at all.
We believe that using a new framework, or buying a faster computer, or typing on a different keyboard, will make us faster, more productive developers, and in our effort to compress the amount of time it takes to build something we have also compressed the amount of time we spend thinking about it. That's why we leave bugs in code.
Quite.
A "small business app" would be far too expensive to build to "NASA" Standards, and furthermore, it would be wholly unnecessary to do so. Think opportunity cost.
I have worked in places where, basically, there was so much money pouring in that the drive to actually ship anything had all but disappeared. Thus the 'axis of perfection' took over: Build the perfect shining crystalline entity, no matter the cost. Rebuild your own tools, even where good, liberally licensed FOSS alternatives already exist. Etc.
I found the latter environments too frustrating to cope with, as I found "making code look nicer" did not lead to an existentially satisfying week.
A "small business app" would be far too expensive to build to "NASA" Standards, and furthermore, it would be wholly unnecessary to do so. Think opportunity cost.
I have worked in places where, basically, there was so much money pouring in that the drive to actually ship anything had all but disappeared. Thus the 'axis of perfection' took over: Build the perfect shining crystalline entity, no matter the cost. Rebuild your own tools, even where good, liberally licensed FOSS alternatives already exist. Etc.
I found the latter environments too frustrating to cope with, as I found "making code look nicer" did not lead to an existentially satisfying week.
Software engineers are more like orthopedic surgeons, who are living memes in the medicine community.
Nsfw ortho meme: https://images.app.goo.gl/fTKFFYP9vTgoFiAs6
Nsfw ortho meme: https://images.app.goo.gl/fTKFFYP9vTgoFiAs6
[deleted]
Building houses became a profession over thousands of years, however, only beginning to have real standards when the masons banded together in guilds. These guilds only attained the power they did because people die when buildings collapse, and important people care when churches collapse. By comparison our profession is, extremely, young and a lot of the software we build doesn’t really matter and doesn’t really have anyone that cares enough about it for there to be consequences.
This is why I both agree and disagree with the article. Because anyone can frankly build a house, and a lot of people around the world, not only do so themselves, they do so poorly. At the same time there are a lot of parts of software that are inaccessible to most software developers.
Banking and medical software developers tend to care quite a lot about your qualifications and even the modern coding interview is sort of there because our profession lack the “trade skill approval” seal that builders and electricians get.
On the flip side of this I live in the city of Aarhus. Some years ago we got a new form of public transportation called Letbanen, which is a street level metro (I’m not sure what they are called in English). It was sort of a standard product that my city bought and it runs in both Norway and Switzerland during their winters that are worse than hours. Last week it was cancelled 5 days out of 7 because the electricity lines were frozen. I love the thing and I don’t mean to complain about it or pretend to know why my city can’t make it work when a city in Norway can, but the fact is that it doesn’t work and tens of thousands of commuters haven’t been able to rely on it for a couple of winters now.
It’s CEO hasn’t changed.
This is a standard product that was build by certified people that keeps people from getting to their jobs without having a car (in Denmark it’s common not to need a car in our larger cities), and yet, there hasn’t been a lot of consequences for it failing the same way for several years.
This is why I both agree and disagree with the article. Because anyone can frankly build a house, and a lot of people around the world, not only do so themselves, they do so poorly. At the same time there are a lot of parts of software that are inaccessible to most software developers.
Banking and medical software developers tend to care quite a lot about your qualifications and even the modern coding interview is sort of there because our profession lack the “trade skill approval” seal that builders and electricians get.
On the flip side of this I live in the city of Aarhus. Some years ago we got a new form of public transportation called Letbanen, which is a street level metro (I’m not sure what they are called in English). It was sort of a standard product that my city bought and it runs in both Norway and Switzerland during their winters that are worse than hours. Last week it was cancelled 5 days out of 7 because the electricity lines were frozen. I love the thing and I don’t mean to complain about it or pretend to know why my city can’t make it work when a city in Norway can, but the fact is that it doesn’t work and tens of thousands of commuters haven’t been able to rely on it for a couple of winters now.
It’s CEO hasn’t changed.
This is a standard product that was build by certified people that keeps people from getting to their jobs without having a car (in Denmark it’s common not to need a car in our larger cities), and yet, there hasn’t been a lot of consequences for it failing the same way for several years.
A bit off-topic, but regarding the reliability of trams: In Switzerland, we have them in basically every city with a population larger than about 50‘000 (just a guesstimate). Maybe it helps that they have much more experience here. I can only remember a single day in the past 10 years when the trams were delayed in my city because everyone was surprised by the early snow and there were no plows ready. But it was the same for cars, busses and cabs.
Do they share lanes for different directions?
I’ve read that they run so well in Norway because the goo they put on the power lines doesn’t get scraped off because they have two sets of rails, one for each direction.
It doesn’t bother me personally, I live inside the city so I typically walk or bike to work, so I haven’t followed the evolving scandal too much.
I’ve read that they run so well in Norway because the goo they put on the power lines doesn’t get scraped off because they have two sets of rails, one for each direction.
It doesn’t bother me personally, I live inside the city so I typically walk or bike to work, so I haven’t followed the evolving scandal too much.
> Banking and medical software developers tend to care quite a lot about your qualifications and even the modern coding interview is sort of there because our profession lack the “trade skill approval” seal that builders and electricians get.
As someone that's worked around banking and finance a fair amount in the last few years, I'd say this is not universally true. I've never worked in the medical sphere, but I have worked on everything from tiny payment systems at SMEs to massive compute systems at banks in the top handful of the fortune 500, to quasi-governmental inter-bank communications bodies, and really I've not seen any more focus on qualifications, nor reliance on 'hard' coding interviews than I've seen elsewhere in software.
Maybe medical is different, AFAICT finance and banking ain't.
As someone that's worked around banking and finance a fair amount in the last few years, I'd say this is not universally true. I've never worked in the medical sphere, but I have worked on everything from tiny payment systems at SMEs to massive compute systems at banks in the top handful of the fortune 500, to quasi-governmental inter-bank communications bodies, and really I've not seen any more focus on qualifications, nor reliance on 'hard' coding interviews than I've seen elsewhere in software.
Maybe medical is different, AFAICT finance and banking ain't.
In medical, you primarily need to be able to handle the bureaucratic processes imposed by the various standards. It may be these processes help with writing good software, but it's perfectly possible to have "compliant" software which is terrible. The problem is attempts to legislate for quality end up legislating for proxies for quality.
I've seen some of that in banking, where retail banks will have things like 15 levels of sign off (ok I jest but it feels like it) before any new release, because the financial bodies that govern them require there to be a set of compelling reasons and a huge doc-trail before anything happens.
But some banks (Starling in the UK) seemed to be able to work around that and have a decent CI/CD story, and as you say - it doesn't usually make the software any better, just adds bureaucracy.
But some banks (Starling in the UK) seemed to be able to work around that and have a decent CI/CD story, and as you say - it doesn't usually make the software any better, just adds bureaucracy.
I work as a senior developer for one of the largest banks in the US at the moment, and have also worked for a subsidiary of the largest medical provider in the city. Neither of these companies had particularly challenging interviews. Generally, if you are IT, the interviews are simple.
The only people who I have met who turn the interview process into a gamut of algorithm puzzles, are people who happen to be very good at them. These also don't tend to be the people running things at banks, let alone large ones.
The only people who I have met who turn the interview process into a gamut of algorithm puzzles, are people who happen to be very good at them. These also don't tend to be the people running things at banks, let alone large ones.
Maybe because these companies see the coding part as almost mechanical and try to tackle the complexity with (often overboarding) design and processes? Problem is that those assume that a tree like divide-and-conquer will reduce complexity in the "leaf-nodes", but as soon as you have a lot of cross-cutting dependencies everybody is shaking that tree.
The problem with "artisanal developers" is that they tend to overestimate their proximity and underestimate how much of a "system" they actually should build. Most of the time they lack domain knowledge, too.
If you can identify the cross-cutting interactions that will result in the biggest risk for the project, and put how to handle those in a design that is communicated well, you can leave freedom how to do the rest and the craftsmen will be appeased. But that needs a good deal of domain (and people) knowlege.
The problem with "artisanal developers" is that they tend to overestimate their proximity and underestimate how much of a "system" they actually should build. Most of the time they lack domain knowledge, too.
If you can identify the cross-cutting interactions that will result in the biggest risk for the project, and put how to handle those in a design that is communicated well, you can leave freedom how to do the rest and the craftsmen will be appeased. But that needs a good deal of domain (and people) knowlege.
I think you’re right. My experiences in the Danish enterprise sector has been that banking and medical are very serious. But that can’t be taken as a universal truth.
I also think it depends on how you define quality. In terms of medical my qualification criteria is based around a 0 deaths or 0 failure rate over a lifetime, not so much what it was build with. Some people would likely disagree with that.
I also think it depends on how you define quality. In terms of medical my qualification criteria is based around a 0 deaths or 0 failure rate over a lifetime, not so much what it was build with. Some people would likely disagree with that.
Serious, with a focus on quality, yes I guess that is there in finance. People's money is at stake so we need to have well designed standards, protocols etc.
But for who gets in the door for implementation work, it's still tech conversations and a bit of "who you know" that count over qualifications and hard tests, in my experience.
But for who gets in the door for implementation work, it's still tech conversations and a bit of "who you know" that count over qualifications and hard tests, in my experience.
In my city the medical companies are always hiring devs. The same ones over and over. They have to be throwing bodies at the situation.
I'm really intrigued to know what the issue is with the tram... I live in Vilnius where the coldest it's been since I've moved here is -20c and our trolley bus network has no issues operating in that. I was thinking maybe it's because you are on the coast, so the salty air causes issues, but so are the most populated cities in Norway. Maybe it's like the UK where they figured they could save money by having less extreme hardy equipment, and so whenever it drops below freezing the entire country grinds to a halt.
> street level metro (I’m not sure what they are called in English)
A tram
A tram
Also a trolley or a street car - and if pulled along via ropes, a cable car when flat or a funicular when ascending.
AFAIK Aarhus Letbane is light rail with a tram-like setup in the city center, but outside the center more traditional light rail: faster than tram and has right-of-way / separate from other traffic.
The answer, I think, is warranties. As soon as software can no longer be delivered “as-is”, the profession will need to change. Hobbies will still exist, just as they do for almost all other professions, but as soon as software is required to be fit for purpose, we will need to get serious. That’s when regulation and (gasp) licensing will need to come in to play.
As soon as, say, a retailer or a bank can be sued to oblivion for bad and/or insecure software, whether it was written in-house or not, the regulations will flow back to the producers of the software.
We are still in the Wild West days. Enjoy it while it lasts. Once we, as a society, start requiring software to actually do what it says it does, the fun times are over…at least professionally. We will still be able to have hobby projects automating sprinklers and lightbulbs and such with the latest unlicensed (edit: un-warrantied, really) Raspberry Pi and Linux.
But at work we will be using buttoned down OSes, programming with buttoned down programming languages, using a (comparatively) small number of professionally licensed third-party libraries, and all this with some painful professionally certified software development methodology.
Edit: for clarity.
As soon as, say, a retailer or a bank can be sued to oblivion for bad and/or insecure software, whether it was written in-house or not, the regulations will flow back to the producers of the software.
We are still in the Wild West days. Enjoy it while it lasts. Once we, as a society, start requiring software to actually do what it says it does, the fun times are over…at least professionally. We will still be able to have hobby projects automating sprinklers and lightbulbs and such with the latest unlicensed (edit: un-warrantied, really) Raspberry Pi and Linux.
But at work we will be using buttoned down OSes, programming with buttoned down programming languages, using a (comparatively) small number of professionally licensed third-party libraries, and all this with some painful professionally certified software development methodology.
Edit: for clarity.
I'm not convinced. As long as someone is capable of inventing a new programming language, new libraries, or a new computer paradigm, there will always be a Wild West. If computers operated on the logic of "what's popular today will stay popular tomorrow", COBOL and Ada would be where C and Python are today.
Buttoned-down OSs existed in the form of mainframes and minicomputers up to the 90s (I'm sure you know what happened to those). Government and corporate standardization often fails more than it succeeds (e.g. respectively, OSI and CORBA), and will eventually follow the trends of the commercial market anyways. Until governments start inventing their own operating systems with 60 years of code and multiple versions of multiple programming languages and standards to reimplement, I wouldn't be so worried.
Right now, state governments and federal agencies are panicking to find COBOL practitioners. That should tell you how even respectable stations can become ghost towns.
Buttoned-down OSs existed in the form of mainframes and minicomputers up to the 90s (I'm sure you know what happened to those). Government and corporate standardization often fails more than it succeeds (e.g. respectively, OSI and CORBA), and will eventually follow the trends of the commercial market anyways. Until governments start inventing their own operating systems with 60 years of code and multiple versions of multiple programming languages and standards to reimplement, I wouldn't be so worried.
Right now, state governments and federal agencies are panicking to find COBOL practitioners. That should tell you how even respectable stations can become ghost towns.
I do agree the profession is trivialized and infantilized, but licensing is not the answer. There are plenty of shitty doctors and builders too.
We don't need licensing and crazy security standards to build the 10000th SaaS app. It doesn't matter if it breaks or falls down or is built by a clown.
There are a few rare places where software actually needs to be very reliable, like say NASA or medical equipment or self-driving cars. Those places typically already have a very different culture and practices.
The trivialization of software comes from the VC/investor class imo. They want to desperately push this idea that everyone can code because it means a continuous supply of cheap labor. Pushing back on that idea is called "gatekeeping". Devs get mindfucked into devaluing themselves, and even if they realize this, they are competing in a pool of others who are similarly mindfucked.
I wish software devs would stop ceding power so easily. The typical arrangement is that you don't decide what to work on, don't decide how long it will take, don't have much say over the organizational structure etc. You don't have to passively accept shitty interviews, the obligation to make your code public, the complete decoupling of decision making from execution etc.
We don't need licensing and crazy security standards to build the 10000th SaaS app. It doesn't matter if it breaks or falls down or is built by a clown.
There are a few rare places where software actually needs to be very reliable, like say NASA or medical equipment or self-driving cars. Those places typically already have a very different culture and practices.
The trivialization of software comes from the VC/investor class imo. They want to desperately push this idea that everyone can code because it means a continuous supply of cheap labor. Pushing back on that idea is called "gatekeeping". Devs get mindfucked into devaluing themselves, and even if they realize this, they are competing in a pool of others who are similarly mindfucked.
I wish software devs would stop ceding power so easily. The typical arrangement is that you don't decide what to work on, don't decide how long it will take, don't have much say over the organizational structure etc. You don't have to passively accept shitty interviews, the obligation to make your code public, the complete decoupling of decision making from execution etc.
Everyone CAN code though -- just like everyone can write a story or hammer a nail. There are different skill levels, that's all. I couldn't write a quality publishable work or build cabinets without several years of honing those crafts.
The responses here really attest that most software engineers don’t know the first thing about regulation. Comments like, “Why would you need to regulate a browser game?”. Anyone can go to Home Depot and build personal toy projects, but as soon as they start selling services with liability, like electrical work, they need certification and need to follow building codes.
There’s absolutely no reason why software couldn’t have similar regulations and certifications for software sold to customers that carries liability.
There’s absolutely no reason why software couldn’t have similar regulations and certifications for software sold to customers that carries liability.
You can already see the effect of regulation on ISO certified enterprise software. It's software which is bought generally by big companies which are themselves certified, so if there's a problem there's somebody to push the blame onto. To put it lightly, it's expensive and it's shit.
I'd be against setting any sort of guideline currently. IT is still too immature and everything is still changing too fast. To make one easy example, setting guidelines for testing would just result in worthless unit tests.
I'd be more favorable to some FAA/EASA style of institution where we evaluate a company/project/people based on its incident-response track record. And even then, I still see too many recipes for abuse.
I'd be against setting any sort of guideline currently. IT is still too immature and everything is still changing too fast. To make one easy example, setting guidelines for testing would just result in worthless unit tests.
I'd be more favorable to some FAA/EASA style of institution where we evaluate a company/project/people based on its incident-response track record. And even then, I still see too many recipes for abuse.
Plenty of non-certified enterprise software is just as bad; is following ISO standards really the reason for their lack of quality?
Definitely not, but I feel the certification is a big reason for it:
- certification is usually an expensive process which doesn't add value by itself - small teams are effectively removed from the talent pool due to the cost requirement, leaving only large (and less efficient) teams/orgs
You artificially reduce competition, to the point that the remaining entities are shielded by the initial barrier to entry and have very little incentive to do anything about it. You can keep raising the certification requirements: it's actually "good" for enterprises which can afford the costs, with basically little or no change in the quality of output.
This is not unique to software development either. I'm not against it by principle, but I'm very skeptical in how certification is applied in _many_ of the contexts I've seen it.
- certification is usually an expensive process which doesn't add value by itself - small teams are effectively removed from the talent pool due to the cost requirement, leaving only large (and less efficient) teams/orgs
You artificially reduce competition, to the point that the remaining entities are shielded by the initial barrier to entry and have very little incentive to do anything about it. You can keep raising the certification requirements: it's actually "good" for enterprises which can afford the costs, with basically little or no change in the quality of output.
This is not unique to software development either. I'm not against it by principle, but I'm very skeptical in how certification is applied in _many_ of the contexts I've seen it.
Some software developers are self taught and do fine. The problem might be that you are referring to it as a "profession." It is for some, but for others it is something they might do more casually, and that should be ok.
Would you agree that a teenager should be able to build a widget for a local business's web site for money? Or should a license be required to do that? Should that same teenager have to get a license to baby sit or mow lawns? Presumably you don't think of baby sitting or lawn mowing as professions, so that's the difference.
Maybe a license should be required to call themselves a "software engineer." But beyond that, I think this article views things in way too black and white terms.
Would you agree that a teenager should be able to build a widget for a local business's web site for money? Or should a license be required to do that? Should that same teenager have to get a license to baby sit or mow lawns? Presumably you don't think of baby sitting or lawn mowing as professions, so that's the difference.
Maybe a license should be required to call themselves a "software engineer." But beyond that, I think this article views things in way too black and white terms.
There's always people who push to regularise and gatekeep the profession, and while they claim to have noble aims it's often simply because they're better at bureaucracy (and surrounding themselves with it for protection) than simply producing viable code.
I always view these pushes with a lot of suspicion given the nature of the people that tend to promote them.
I always view these pushes with a lot of suspicion given the nature of the people that tend to promote them.
Writing software has proved to be one of the most successful professions of the last 30-40 years, yes, there have been (and there certainly will be) mishaps, but the world has changed considerably (for good or for worse) because of our profession. Software has indeed eaten the world.
Had this profession been a guild-like thing from the very beginning as the author of this article suggests then I think none of this would have happened.
Had this profession been a guild-like thing from the very beginning as the author of this article suggests then I think none of this would have happened.
I don't take 'software eating the world' as positive. Finance has eaten the world as well, does that sound so good? The only reason it has a positive connotation is because the people quoting it tend to profit from it.
If we took software engineering seriously overall we'd still have all the things where that's already the case. Compilers, machinery, infrastructure and so on. Sure we maybe would only have two delivery platforms that don't lose your data instead of 50 that do, but is that so bad?
For many years now every time people discuss raising standards in the industry there's always the line of argument that we lose a whole bunch stuff. To me it sounds like arguing that banning people from pouring lead into the river loses you a bunch of companies. Sure, but good riddance.
If we took software engineering seriously overall we'd still have all the things where that's already the case. Compilers, machinery, infrastructure and so on. Sure we maybe would only have two delivery platforms that don't lose your data instead of 50 that do, but is that so bad?
For many years now every time people discuss raising standards in the industry there's always the line of argument that we lose a whole bunch stuff. To me it sounds like arguing that banning people from pouring lead into the river loses you a bunch of companies. Sure, but good riddance.
I'm not sure that the author has experience in the aerospace software industry. Software development there is a totally different ball game compared to web site / consumer app development. Automotive is also very different though not to the same standard as aerospace.
There are rigorous standards that will make your eyes bleed https://en.wikipedia.org/wiki/DO-178C and you won't have any fun with the latest frameworks and toys. It's designed to be boring and safe. The development process is excruciating. I remember from my short experience fun things like the person who writes the spec is not allowed to write the code and the person who writes the code is not allowed to write the test cases. Code coverage is not enough. You have to try to cover every combination of branching. https://en.wikipedia.org/wiki/Modified_condition/decision_co...
But in the end as the Boeing example shows. If you have people willing to subvert the regulations for their own personal profit then things will break.
There are rigorous standards that will make your eyes bleed https://en.wikipedia.org/wiki/DO-178C and you won't have any fun with the latest frameworks and toys. It's designed to be boring and safe. The development process is excruciating. I remember from my short experience fun things like the person who writes the spec is not allowed to write the code and the person who writes the code is not allowed to write the test cases. Code coverage is not enough. You have to try to cover every combination of branching. https://en.wikipedia.org/wiki/Modified_condition/decision_co...
But in the end as the Boeing example shows. If you have people willing to subvert the regulations for their own personal profit then things will break.
Automotive: It looks really great for management, to minimize the liability risk. Look what great processes we have installed to avoid all kinds of problems.
Reality:
The code is written by the lowest bidder. This might be people with some form of formal qualifications, but also often is people who have no idea how a car is supposed to work, who do not even have a license to drive one. Imagine someone implementing a web app without ever having used a web browser.
The specifications are written by non-software engineers, and more often than not they contain a code-like description of the software, without any significant explanation. That's code written by people with no clue about software.
The tests may provide any coverage you can dream of, but they are unfit to detect any kind of bug. Which is obvious because the authors of the code and test have no idea about what problem the code is supposed to solve. And the only goal is to prove coverage not to find bugs.
In the end it only works because there is different people, who know how cars work, and test everything manually. At that point, coverage is of no concern at all, and bugs stay undetected, but the result might be just good enough. Also, it helps that (from a pure software point of view) most automotive software isn't exactly highly complicated.
Reality:
The code is written by the lowest bidder. This might be people with some form of formal qualifications, but also often is people who have no idea how a car is supposed to work, who do not even have a license to drive one. Imagine someone implementing a web app without ever having used a web browser.
The specifications are written by non-software engineers, and more often than not they contain a code-like description of the software, without any significant explanation. That's code written by people with no clue about software.
The tests may provide any coverage you can dream of, but they are unfit to detect any kind of bug. Which is obvious because the authors of the code and test have no idea about what problem the code is supposed to solve. And the only goal is to prove coverage not to find bugs.
In the end it only works because there is different people, who know how cars work, and test everything manually. At that point, coverage is of no concern at all, and bugs stay undetected, but the result might be just good enough. Also, it helps that (from a pure software point of view) most automotive software isn't exactly highly complicated.
MC/DC coverage is weaker than path coverage, which is what you describe. MC/DC coverage is also not as useful outside control systems, as other large systems usually have more side effects and path interdependencies. Conversely, path coverage measurements are computationally intensive at best and uncomputable at worst.
> Systemically, I'm concerned that there is a lack of professional liability, rigorous industry best practices, and validation in the software industry which contributes to why we see [...] stories floating around our industry publications about people being concerned about the possibility of a remotely exploitable lunar lander on Mars.
If a Lunar Lander were to be on Mars, is only software to blame? /s
If a Lunar Lander were to be on Mars, is only software to blame? /s
I know a ton of smart people who got a degree in something other than computer science and ended up as successful software engineers. All of those people would need to waste additional years of their life if software engineering profession was regulated.
For me personally the lack of regulation is one of its best features of this profession. We already have to deal with enough corporate bullshit to add to it licensing and regulations.
For me personally the lack of regulation is one of its best features of this profession. We already have to deal with enough corporate bullshit to add to it licensing and regulations.
While it's easy to write a small piece of code, it's much harder to craft a coherent system of some kind to do anything non-trivial.
Does that mean we need some test or professional credential to serve as a "gate" between small and large?
I think that the only thing that helps here is experience. And a piece of paper doesn't really help with that.
I also think that good developers are able to be self-deprecating. Just because we muse over not working or writing bad code, we don't want to deliver a bad product or project -- usually the user doesn't see the code. So, I'm fine with being a bit less "professional", if my users are happy with my work product and it makes me seem more approachable and human.
I also think that good developers are able to be self-deprecating. Just because we muse over not working or writing bad code, we don't want to deliver a bad product or project -- usually the user doesn't see the code. So, I'm fine with being a bit less "professional", if my users are happy with my work product and it makes me seem more approachable and human.
> I also think that good developers are able to be self-deprecating.
This also holds for doctors.
This also holds for doctors.
So...
There are a bunch of loosely connected elements here. The primary one, IMO, is the "anyone can be a dev" ethos.
A lot of this ethos is historical. Programming does not have long decades or centuries of history, like civil engineering, medicine or whatnot. In fact, programming was (relatively) recently something that users were expected to do. "Buy computer, program it." was the model into the 90s.
Related is the fact that programming moves fast. Building techniques change, but much slower than software. Most civil architects work all their life building similar constructions with similar materials. That lends to a lot more formalism.
Idk... I'll grant that there are a lot of downsides to openness. There are upsides too though.
On balance, I feel that software's rare status as a "free profession" in anachronistic terms, is good.
Also, I think that expansionary economics plays a role. There's more software work every day. Software developers aren't under the same economic pressure as other professions. Lawyers would be hurt financially if accreditations and qualifications were taken out of law.
It's hard to know what a world with licence to code looks like. Maybe we have a lot less software, but it's more secure. Maybe we know a lot less about the software we have.
Finally, I consider the importance of OSS, FOSS and volunteer made software a strength, not a weakness. That's a whole other thread though.
There are a bunch of loosely connected elements here. The primary one, IMO, is the "anyone can be a dev" ethos.
A lot of this ethos is historical. Programming does not have long decades or centuries of history, like civil engineering, medicine or whatnot. In fact, programming was (relatively) recently something that users were expected to do. "Buy computer, program it." was the model into the 90s.
Related is the fact that programming moves fast. Building techniques change, but much slower than software. Most civil architects work all their life building similar constructions with similar materials. That lends to a lot more formalism.
Idk... I'll grant that there are a lot of downsides to openness. There are upsides too though.
On balance, I feel that software's rare status as a "free profession" in anachronistic terms, is good.
Also, I think that expansionary economics plays a role. There's more software work every day. Software developers aren't under the same economic pressure as other professions. Lawyers would be hurt financially if accreditations and qualifications were taken out of law.
It's hard to know what a world with licence to code looks like. Maybe we have a lot less software, but it's more secure. Maybe we know a lot less about the software we have.
Finally, I consider the importance of OSS, FOSS and volunteer made software a strength, not a weakness. That's a whole other thread though.
Mate, don't point it out! Just enjoy how nice it is being able to be a "professional" without having to be a professional and regulated all the time. Imagine in ten years if they brought in a bunch of tests you had to do to get a programmers license - I'd honestly probably just change career, and in the end we'd just end up with a further shortage of programmers.
I use basically nothing of what I learned at uni to do my job. Everyone knows that the best devs usually didn't have any formal education. It's all based on merit - let's just keep it that way as it seems to work fine.
As a counter example - I'm currently living in Germany and I need a guy to fix up the walls of my house. Problem is it's impossible to find anyone to do it because there's not enough qualified craftsmen in the country. Everything is so tightly regulated that nothing gets done anymore, so instead there's a move towards folk trying to do it for themselves and buying materials from non-regulated big American-style hardware stores. Wouldn't life be better if we all had a broader skill set and were able to hack things together ourselves in an unofficial capacity like programmers do?
I use basically nothing of what I learned at uni to do my job. Everyone knows that the best devs usually didn't have any formal education. It's all based on merit - let's just keep it that way as it seems to work fine.
As a counter example - I'm currently living in Germany and I need a guy to fix up the walls of my house. Problem is it's impossible to find anyone to do it because there's not enough qualified craftsmen in the country. Everything is so tightly regulated that nothing gets done anymore, so instead there's a move towards folk trying to do it for themselves and buying materials from non-regulated big American-style hardware stores. Wouldn't life be better if we all had a broader skill set and were able to hack things together ourselves in an unofficial capacity like programmers do?
>Imagine in ten years if they brought in a bunch of tests you had to do to get a programmers license -
You mean like leet code, white bording and take home tests? Except that instead of being standardized/credentialized, every company has a different variation you need to study or do unpaid work, for every interview.
Yeah, good thing we don't have that kind of testing, this is so much better./s
You mean like leet code, white bording and take home tests? Except that instead of being standardized/credentialized, every company has a different variation you need to study or do unpaid work, for every interview.
Yeah, good thing we don't have that kind of testing, this is so much better./s
> You mean like leet code, white bording and take home tests? Except that instead of being standardized/credentialized, every company has a different variation you need to study or do unpaid work, for every interview.
We don't test our accounting candidates on advanced accounting theories. We just trust the certification and the experience on their resume.
But we ask our developer candidates with take home tests. I wonder why. /s
We don't test our accounting candidates on advanced accounting theories. We just trust the certification and the experience on their resume.
But we ask our developer candidates with take home tests. I wonder why. /s
If only interviews focused on rigorous optimization knew how to optimize the process by having applicants pass part of it once, caching the result!
Yeah, no.
Anyone could build furniture without any licenses.
It's like anyone can be a salesman, but the more serious consequences something has, more regulation there is for selling it.
Regulation based on consequences already exists in IT sector as others have stated in this thread.
Anyone could build furniture without any licenses.
It's like anyone can be a salesman, but the more serious consequences something has, more regulation there is for selling it.
Regulation based on consequences already exists in IT sector as others have stated in this thread.
Always good to refer back to RMS's Right To Read to see what stage people are proposing to implement next.
https://www.gnu.org/philosophy/right-to-read.en.html
Now Licensed and Bonded programmers are being proposed. Who thought this was science fiction, once upon a time?
RMS is a Cassandra of our time.
https://www.gnu.org/philosophy/right-to-read.en.html
Now Licensed and Bonded programmers are being proposed. Who thought this was science fiction, once upon a time?
RMS is a Cassandra of our time.
Like so many proposals, this is just a blog post, destined to be shared and ballyhooed about, never to be made into policy of any substance.
Next: Programmers with Imperial Conditioning.
> Software practitioners should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice software engineering.
That seems like something that might make more sense if done minimally. For example, if we freely granted anyone who wanted a professional-license, then basically just publicly affixed warnings of blatant misconduct (like deliberately sabotaging an employer's code), then that might seem sensible.
However, professional-licensing schemes seem prone to becoming cartels.
Eventually we'll probably want a (web-of-trust)-like system to replace the ad-hoc strategies for vetting business-associates used historically. Professional-licensing bodies seem sorta similar in principle, though their heavy centralization/bureaucracy seems prone to corruption and chilling-effects while also being of questionable effectiveness.
That seems like something that might make more sense if done minimally. For example, if we freely granted anyone who wanted a professional-license, then basically just publicly affixed warnings of blatant misconduct (like deliberately sabotaging an employer's code), then that might seem sensible.
However, professional-licensing schemes seem prone to becoming cartels.
Eventually we'll probably want a (web-of-trust)-like system to replace the ad-hoc strategies for vetting business-associates used historically. Professional-licensing bodies seem sorta similar in principle, though their heavy centralization/bureaucracy seems prone to corruption and chilling-effects while also being of questionable effectiveness.
Pointless blog post which generalizes from an extreme case (Boeing) to draw hyperbolic conclusions.
Let’s start with the three major fallacies
1. Software Engineer is a monolithic profession. There are a great many specializations.
2. Software Engineering is comparable to trades and other engineer professions. Classical professions have existed for millennia, and are built on a foundation of failures through anti-fragility. We understand really well how to build houses and bridges. Software is a nascent profession.
3. Societal problems can be solved by software engineers. This is a problem of law and consequences. The Babylionians had a great thing with Hammurabi’s Code. When data protection laws will severely punish personal data leaks, then banks and other financial firms will take great expense to prevent them.
Let’s start with the three major fallacies
1. Software Engineer is a monolithic profession. There are a great many specializations.
2. Software Engineering is comparable to trades and other engineer professions. Classical professions have existed for millennia, and are built on a foundation of failures through anti-fragility. We understand really well how to build houses and bridges. Software is a nascent profession.
3. Societal problems can be solved by software engineers. This is a problem of law and consequences. The Babylionians had a great thing with Hammurabi’s Code. When data protection laws will severely punish personal data leaks, then banks and other financial firms will take great expense to prevent them.
Shouldn't that be a "cannot solve" in the 3rd paragraph?
This is basic economics - a lot of different approaches were tried and components overwhelmingly developed by unpaid volunteers on an as-is basis turned out to be cheap and of high quality when the marginal cost of copying work gets really low.
The issue of bugs doesn't go away from having more certification. Formal methods might be able to have an impact, but that can't produce software at the rate we need it produced to get real value.
No-one sat down and decided to use open source - quite the reverse, it rolled over any number of opponents by being more reliable in the long term and cheaper. If the same approach worked in other industries it'd be used there too.
The issue of bugs doesn't go away from having more certification. Formal methods might be able to have an impact, but that can't produce software at the rate we need it produced to get real value.
No-one sat down and decided to use open source - quite the reverse, it rolled over any number of opponents by being more reliable in the long term and cheaper. If the same approach worked in other industries it'd be used there too.
There are fields where software development practices are regulated by standards (i.e. medical devices). I don’t see the need to regulate all areas. Moreover, anyone can complete a few tutorials and do something useful for society using software: a website, a mobile app, etc. Why would we forego these benefits?
There are situations where mitigating risks is absolutely necessary (again, healthcare is a good example), but in most cases, it’s best to let individuals decide how to best deal with those risks, taking into account their domains and resources to determine how to best produce value.
There are situations where mitigating risks is absolutely necessary (again, healthcare is a good example), but in most cases, it’s best to let individuals decide how to best deal with those risks, taking into account their domains and resources to determine how to best produce value.
I would regulate all areas that store private information. It is just shocking that developers handling this data are still writing SQL injection vulnerabilities, storing it in unprotected databases in this day and age.
The storage of private information is already regulated, particularly in Europe, or in American Healthcare settings.
I hope even author of this article would agree that it's stupid to require licence for building a simple browser game.
Yet it feels that building essential life- saving machines running on windows XP with internet access should be a crime.
I think if anything we need regulation on the industry-level so that e.g. plane controllers won't be running on operating system which can restart and update without users consent.
It would make prefect sense to require certain level of certification to work on code in some selected industries.
Yet it feels that building essential life- saving machines running on windows XP with internet access should be a crime.
I think if anything we need regulation on the industry-level so that e.g. plane controllers won't be running on operating system which can restart and update without users consent.
It would make prefect sense to require certain level of certification to work on code in some selected industries.
When people think of industries that need regulation, it’s aviation and healthcare. But the fact is there is so much liability in every industry and there’s nothing protecting consumers from reckless incompetence or misuse of personal data.
Ethics is at the core of all other Engineering disciplines, and there’s no reason we couldn’t regulate Software similarly. It protects the public.
Ethics is at the core of all other Engineering disciplines, and there’s no reason we couldn’t regulate Software similarly. It protects the public.
Once said that (IMHO) regulation is not a solution to poor software, something must be done.
Software (at least business tools) tend to be monetized/sold (at a high price) by corporations (that employ programmers that write these programs, and are well paid) as tools to actually do something.
When the something is not delivered (or it is not delivered correctly) there are consequences (time lost, money lost) for the customer/client that bought the tool (or subscribed to a service), as the tool is needed (or only useful) for the "main" activity of the client.
Yet - usually - neither the corporation (that gets the money from the client), nor the programmers (that get the money from the corporation) consider these cases as anything more than "oh, a bug, didn't see/foresee it".
In any other more material contract when you don't deliver the goods (or don't deliver them in time, or they are not up to the required standards/quality) you pay a penalty, and after you fail a few deliveries you are likely to go out of the market.
Somehow, in the software world, it seems like it is always a "oops, will fix next time".
Software (at least business tools) tend to be monetized/sold (at a high price) by corporations (that employ programmers that write these programs, and are well paid) as tools to actually do something.
When the something is not delivered (or it is not delivered correctly) there are consequences (time lost, money lost) for the customer/client that bought the tool (or subscribed to a service), as the tool is needed (or only useful) for the "main" activity of the client.
Yet - usually - neither the corporation (that gets the money from the client), nor the programmers (that get the money from the corporation) consider these cases as anything more than "oh, a bug, didn't see/foresee it".
In any other more material contract when you don't deliver the goods (or don't deliver them in time, or they are not up to the required standards/quality) you pay a penalty, and after you fail a few deliveries you are likely to go out of the market.
Somehow, in the software world, it seems like it is always a "oops, will fix next time".
It seems that most people miss the point.
The software we create is a direct reflection of the problem that is being solved. If you are hired by a small 3 person startup company to help them build an MVP on a budget for an untested business model, then you _should_ expect garbage, because that is precisely what is being asked/paid for.
Writing systems software for flight controls or similar use case where loss of life might occur? Well then you are _still_ being persuaded by a project manager and senior leadership to find a balance between cost and quality... but since lawsuits get more expensive when lives are lost, you have more quality control (yes, ethics should be more important than money, but that is not the case).
The _business_ makes the bulk of the decision on quality and safety, NOT the person in front of the keyboard. In most cases (web, e-commerce, SaaS, games, etc.), there is more business value to be had from releasing buggy garbage _fast_ rather than thoughtful and well tested features. You can always roll out a fix next sprint.
Our profession _is_ full of immature practitioners, and it has a long way to go if we are going to fix this, but there are powerful market forces at play currently and for the vast majority of us it makes more sense to _swim with the current_ and extract as much value from your career as possible... and if we can be spoiled brats that demand more vacation and free food/drinks, why not?
It's difficult to say which is better, 20 years ago we were more professional, but today we have a lot more leverage. I miss the professional attitudes and behaviour, but I've gotten used to the outsized compensation and easy job market, and in all honesty, wouldn't turn back. ¯\_ (ツ)_/¯
The software we create is a direct reflection of the problem that is being solved. If you are hired by a small 3 person startup company to help them build an MVP on a budget for an untested business model, then you _should_ expect garbage, because that is precisely what is being asked/paid for.
Writing systems software for flight controls or similar use case where loss of life might occur? Well then you are _still_ being persuaded by a project manager and senior leadership to find a balance between cost and quality... but since lawsuits get more expensive when lives are lost, you have more quality control (yes, ethics should be more important than money, but that is not the case).
The _business_ makes the bulk of the decision on quality and safety, NOT the person in front of the keyboard. In most cases (web, e-commerce, SaaS, games, etc.), there is more business value to be had from releasing buggy garbage _fast_ rather than thoughtful and well tested features. You can always roll out a fix next sprint.
Our profession _is_ full of immature practitioners, and it has a long way to go if we are going to fix this, but there are powerful market forces at play currently and for the vast majority of us it makes more sense to _swim with the current_ and extract as much value from your career as possible... and if we can be spoiled brats that demand more vacation and free food/drinks, why not?
It's difficult to say which is better, 20 years ago we were more professional, but today we have a lot more leverage. I miss the professional attitudes and behaviour, but I've gotten used to the outsized compensation and easy job market, and in all honesty, wouldn't turn back. ¯\_ (ツ)_/¯
I see a lot of flaws in this article.
He claims that open source software trivializes our profession ignoring the fact that most of the time the open source as is software is the best there is.
He talks about all these examples of software falling boeings, financial firms, lunar landers which by the way are all not open source.
Additionally the boeing case was not even a software failure, if I recall correctly one of the sensors would physically get stuck in a wrong position, you know the kind of physical system designed by licensed engineers.
Then he proceeds to list a number of perceived problems in the software industry, failing to see that they also exist in other industries, these are not symptoms of lack of professionalism they are the reality of profit seeking taken to the extreme.
Liability is a thing, we don't need licensing because we are liable for the code we sell and the services we provide.
Licensing does not fix any of these problems all of the bridges that have fallen, all of the planes that have crashed have been built by licensed engineers, the solution in engineering has been regulations.
He claims that open source software trivializes our profession ignoring the fact that most of the time the open source as is software is the best there is.
He talks about all these examples of software falling boeings, financial firms, lunar landers which by the way are all not open source.
Additionally the boeing case was not even a software failure, if I recall correctly one of the sensors would physically get stuck in a wrong position, you know the kind of physical system designed by licensed engineers.
Then he proceeds to list a number of perceived problems in the software industry, failing to see that they also exist in other industries, these are not symptoms of lack of professionalism they are the reality of profit seeking taken to the extreme.
Liability is a thing, we don't need licensing because we are liable for the code we sell and the services we provide.
Licensing does not fix any of these problems all of the bridges that have fallen, all of the planes that have crashed have been built by licensed engineers, the solution in engineering has been regulations.
Although a little bit polemic I like the article. I wrote a comment a few days ago that kind of hit the same note.
Almost all developers I know can make things work. They get the job done and thats fine. Like some people here wrote, for many applications thats enough. But already one "level" higher, density gets way lower. I only have my subjective feelings but as far as I can tell, developers who not only get things done but have a okayish code quality and an acceptable test coverage are so much more rare. True software master craftsman are almost not existing.
I guess our view of the software industry here is a bit distorted. Naturally people who are active here (or on other sites) dont represent the big mass of software developers. The top people in our software industry can keep it up with the top people of other industries (at least I hope and think so) but the entry and average level is not on the same level as the entry or average level in other industries. Thats where good and structured qualification paths can help.
Almost all developers I know can make things work. They get the job done and thats fine. Like some people here wrote, for many applications thats enough. But already one "level" higher, density gets way lower. I only have my subjective feelings but as far as I can tell, developers who not only get things done but have a okayish code quality and an acceptable test coverage are so much more rare. True software master craftsman are almost not existing.
I guess our view of the software industry here is a bit distorted. Naturally people who are active here (or on other sites) dont represent the big mass of software developers. The top people in our software industry can keep it up with the top people of other industries (at least I hope and think so) but the entry and average level is not on the same level as the entry or average level in other industries. Thats where good and structured qualification paths can help.
When you check e.g. building code or surgical procedures there is always a reason for something. E.g. use nails not screws because screws are brittle. Wash hands before surgery because bacteria on your hands might kill your patient. But all of this needed to be proven at some point. With software, best practices often end up being "I would do it differently, hence it's a code smell". In this way developers are less like serious engineers and more like simple craftsman. They learned one way from someone (their first job, the blogger they respect etc.) and that's it, that's the correct way. That's how plumbers etc. operate.
So the first step in becoming serious is proving why one thing is important and why we should do it. I am experienced in a way, and I mostly really don't know. I've seen projects built real serious that were impossible to change and duct taped things that were a breeze. So it's not what most people think.
So the first step in becoming serious is proving why one thing is important and why we should do it. I am experienced in a way, and I mostly really don't know. I've seen projects built real serious that were impossible to change and duct taped things that were a breeze. So it's not what most people think.
I don’t think there is any indication that licensing requirements developers would improve software quality. There are countries and industries (banking) where a far greater share of job adverts ask for a degree. They make some of the shoddiest software I have ever seen.
Most quality issues are down to economic constraints and priorities. It’s not hard to hire cheap degree qualified devs and set the deadlines so tightly that only garbage can ever come out of it. Most terrible software I have seen is terrible because no one cares to make it better.
Let’s not forget that historically a lot of licensing restrictions had more to do with protectionism and gatekeeping than with quality. Most countries have a long list of absolutely laughable restrictions that are justified by ridiculous claims about quality control.
I think where quality is an absolute requirement, it’s the software itself that should be inspected and licensed, not the developers. After all, users rely on software, not on degrees.
Most quality issues are down to economic constraints and priorities. It’s not hard to hire cheap degree qualified devs and set the deadlines so tightly that only garbage can ever come out of it. Most terrible software I have seen is terrible because no one cares to make it better.
Let’s not forget that historically a lot of licensing restrictions had more to do with protectionism and gatekeeping than with quality. Most countries have a long list of absolutely laughable restrictions that are justified by ridiculous claims about quality control.
I think where quality is an absolute requirement, it’s the software itself that should be inspected and licensed, not the developers. After all, users rely on software, not on degrees.
It's not a bug it's a feature!
LICENSING WON'T INCREASE QUALITY OR SUPPLY Adding licensing to be a software engineer will not produce more or better software developers.
LICENSING OBSOLETE IN FEW YEAR The software industry changes very fast and that's also because it doesn't have a ton of beuracracy weighting on it (yet). Try standardising exams to be a software developers, then everyone will have to know a language or practice of 10-20 years ago! Already this is happening with universities that are stuck teaching Java while clearly everyone should have moved to Javascript/Typescript/Python/Go/Rust by now.
LICENSING ONLY GIVES ADVANTAGE TO SENIOR DEVELOPERS Finally, this type of licensing are also a way for the people already INSIDE to close the gate and allow less younger talent in to compete with them. Don't close the gate, move up in your career as software engineer and become an entrepreneur or manager and help younger developers rise up too.
LICENSING WON'T INCREASE QUALITY OR SUPPLY Adding licensing to be a software engineer will not produce more or better software developers.
LICENSING OBSOLETE IN FEW YEAR The software industry changes very fast and that's also because it doesn't have a ton of beuracracy weighting on it (yet). Try standardising exams to be a software developers, then everyone will have to know a language or practice of 10-20 years ago! Already this is happening with universities that are stuck teaching Java while clearly everyone should have moved to Javascript/Typescript/Python/Go/Rust by now.
LICENSING ONLY GIVES ADVANTAGE TO SENIOR DEVELOPERS Finally, this type of licensing are also a way for the people already INSIDE to close the gate and allow less younger talent in to compete with them. Don't close the gate, move up in your career as software engineer and become an entrepreneur or manager and help younger developers rise up too.
Yeah, licensing has always seemed to me like a sort of rent-seeking; artificially keeping the supply low to improve the pay of the insiders. It's not like we need that in software right now.
Besides, software is a business that's surprisingly low on the bullshitisation that's taking over almost every other "serious" job, where people have ever less time to do their actual job and spend more time documenting how they do their job and justifying their choices with after-the-fact narratives that don't accomplish anything other than make someone look busy while producing nothing of value and increasing consumer costs.
Besides, software is a business that's surprisingly low on the bullshitisation that's taking over almost every other "serious" job, where people have ever less time to do their actual job and spend more time documenting how they do their job and justifying their choices with after-the-fact narratives that don't accomplish anything other than make someone look busy while producing nothing of value and increasing consumer costs.
The irony being that it's software that's allowed the massive
expansion of bullshitisation and the transformation of society into
performative simulation of human life.
(this isn't an objection/rant to your post, it's just an opportune point to reply on how this relates to software quality)
There are people in the world that create things. Then there are people in the world that take those things, and figure out how to make money. Then they seek to direct those who create.
They take software and turn it to inappropriate ends, misuse it, abuse it, make it a panacea, a weapon, then a crutch. They build whole cities and societies around things they neither understand nor appreciate the origins of.
And we let them.
We build doll houses. They rent them out to a real family.
It isn't that software cannot be engineering, but to make it so we'd have to change a whole stack of human relations and the world doesn't seem ready for that.
I studied software engineering at the end of my CSEE degree and in 30 years, in all but a few medical/military applications where ISO documents properly govern _what_ is used, and _how_ it's used (not who makes it) I've been laughed at for even suggesting the principles I learned in software engineering.
Software is still an experimental rocket burning fuel as fast it can to achieve escape velocity.
There is not enough space in a short post to express how ridiculously I think the "software industry" is structured, but the solution is not regulation, which will make almost everything worse and kill innovation stone-dead.
The solution lies with us. When programmers have ethics and courage, enough to say "no", it will make a vast difference.
(this isn't an objection/rant to your post, it's just an opportune point to reply on how this relates to software quality)
There are people in the world that create things. Then there are people in the world that take those things, and figure out how to make money. Then they seek to direct those who create.
They take software and turn it to inappropriate ends, misuse it, abuse it, make it a panacea, a weapon, then a crutch. They build whole cities and societies around things they neither understand nor appreciate the origins of.
And we let them.
We build doll houses. They rent them out to a real family.
It isn't that software cannot be engineering, but to make it so we'd have to change a whole stack of human relations and the world doesn't seem ready for that.
I studied software engineering at the end of my CSEE degree and in 30 years, in all but a few medical/military applications where ISO documents properly govern _what_ is used, and _how_ it's used (not who makes it) I've been laughed at for even suggesting the principles I learned in software engineering.
Software is still an experimental rocket burning fuel as fast it can to achieve escape velocity.
There is not enough space in a short post to express how ridiculously I think the "software industry" is structured, but the solution is not regulation, which will make almost everything worse and kill innovation stone-dead.
The solution lies with us. When programmers have ethics and courage, enough to say "no", it will make a vast difference.
>The solution lies with us. When programmers have ethics and courage, enough to say "no", it will make a vast difference.
In the context of your statement, how are you defining "ethics"? One could argue that it's completely ethical to trade one's information or skills on a subject to the highest bidder. That's how a job works. What someone does with a knife or book doesn't concern a storekeeper after the purchase. Absent any evidence of one's rights being violated, what does it matter what another person chooses to do after one has been compensated? He has his life and you have yours.
>They take software and turn it to inappropriate ends, misuse it, abuse it, make it a panacea, a weapon, then a crutch. They build whole cities and societies around things they neither understand nor appreciate the origins of.
In this context, who is or should be the arbiter of "inappropriate", "misuse", "abuse", etc. ? I agree with you that many people don't understand the totality or consequences of what they purchase. But is that to be held against them as evidence of "unworthiness" or that they must patronized?
In the context of your statement, how are you defining "ethics"? One could argue that it's completely ethical to trade one's information or skills on a subject to the highest bidder. That's how a job works. What someone does with a knife or book doesn't concern a storekeeper after the purchase. Absent any evidence of one's rights being violated, what does it matter what another person chooses to do after one has been compensated? He has his life and you have yours.
>They take software and turn it to inappropriate ends, misuse it, abuse it, make it a panacea, a weapon, then a crutch. They build whole cities and societies around things they neither understand nor appreciate the origins of.
In this context, who is or should be the arbiter of "inappropriate", "misuse", "abuse", etc. ? I agree with you that many people don't understand the totality or consequences of what they purchase. But is that to be held against them as evidence of "unworthiness" or that they must patronized?
> In the context of your statement, how are you defining "ethics"? One
could argue that it's completely ethical...
Really glad you asked that Dracophoenix! :)
Indeed, it's such an interesting and extensive topic that I am writing a book (aprox. 500pp) on it. You will be able to read it in a few months.
Meanwhile have a look at this one [1] which lightly touches on some of the issues that intersect ethics and code. Cheers.
https://digitalvegan.net
Really glad you asked that Dracophoenix! :)
Indeed, it's such an interesting and extensive topic that I am writing a book (aprox. 500pp) on it. You will be able to read it in a few months.
Meanwhile have a look at this one [1] which lightly touches on some of the issues that intersect ethics and code. Cheers.
https://digitalvegan.net
Licensing is untenable for software development outside of space or military. Companies would just offshore all work to somewhere with lesser requirements.
On the other hand, things like barbering, teaching, truck driving, blood drawing, supervisory civil engineering, and the like can't be contracted remotely, so they naturally gravitate towards licensure in many cases.
On the other hand, things like barbering, teaching, truck driving, blood drawing, supervisory civil engineering, and the like can't be contracted remotely, so they naturally gravitate towards licensure in many cases.
> Companies would just offshore all work to somewhere with lesser requirements.
That didn't work out so great for Boeing.
That didn't work out so great for Boeing.
Airliners are the most complex products the world has to offer so not a good example.
And if marketability to airline executives and time to market dunk on the engineering culture then it doesn't matter who does the work and with what credentials -- there will be screw ups.
And if marketability to airline executives and time to market dunk on the engineering culture then it doesn't matter who does the work and with what credentials -- there will be screw ups.
I think software developers are highly underpaid. The value delivered by solving a problem permanently is worth far more than $5-$10k a week.
You end up working for a year at $300k to produce something that yields tens of millions of dollars for the company. Bad fucking deal.
You end up working for a year at $300k to produce something that yields tens of millions of dollars for the company. Bad fucking deal.
I do think so too. Don't work for others than.
Boostrap your own B2B SaaS company with Silicon Valley savings while living in cheap places!
I worked 1 years in Silicon Valley and with that salary I was able to live for 3 years around Europe and South East Asia while building my company waiterio.com
Now after 9 years I finally have the same salary of what I would be paid in Silicon Valley but I created a new company, created jobs and I won't sell to Google/Apple/Microsoft/Amazon to create monster monopoly.
A
Hold on. I think only a handful of geniuses understands the whole stack: from electrons moving in your PC to a hyperlink. Even they are really only good (experienced) at one thin slice of that big layered cake.
Most in this trade work on a layer near the top (closer to the end-user) coding just a bit of logic and gluing together building blocks in order to provide a solution to real needs.
The trade seems trivial because the hard work (millions of lines of code) is already done. And that right there is the brilliance of the whole thing: take any layer apart and it will be done of smaller pieces which have been debugged to the point of being practically flawless (yes, we still find bugs in code that is out there for years, but that is the exception not the rule).
On the other hand, if you want accountability and guaranteed results, you have them already: formal software development processes used by the likes of NASA or the military.
Most in this trade work on a layer near the top (closer to the end-user) coding just a bit of logic and gluing together building blocks in order to provide a solution to real needs.
The trade seems trivial because the hard work (millions of lines of code) is already done. And that right there is the brilliance of the whole thing: take any layer apart and it will be done of smaller pieces which have been debugged to the point of being practically flawless (yes, we still find bugs in code that is out there for years, but that is the exception not the rule).
On the other hand, if you want accountability and guaranteed results, you have them already: formal software development processes used by the likes of NASA or the military.
Thinking about the accounting industry after reading the post and comments:
Many accountants have non-accounting degrees, are self-taught, work without a license, etc. but a license is required to “hold out as a Certified Public Accountant (CPA)” and perform some regulated services.
The CPA license provides the skills/knowledge floor that other comments have mentioned so being a CPA offers signaling even if a role doesn’t require the license.
There aren’t any buildings falling or patients dying but all CPAs have annual continuing education requirements (including ethics classes) and the Code of Professional Conduct has a strong focus on maintaining public trust in the profession.
There’s a lot of professional judgment involved but most of the Code boils down to: keep the public interest in mind, act with integrity, be competent, do things your professional peers would deem reasonable.
Many accountants have non-accounting degrees, are self-taught, work without a license, etc. but a license is required to “hold out as a Certified Public Accountant (CPA)” and perform some regulated services.
The CPA license provides the skills/knowledge floor that other comments have mentioned so being a CPA offers signaling even if a role doesn’t require the license.
There aren’t any buildings falling or patients dying but all CPAs have annual continuing education requirements (including ethics classes) and the Code of Professional Conduct has a strong focus on maintaining public trust in the profession.
There’s a lot of professional judgment involved but most of the Code boils down to: keep the public interest in mind, act with integrity, be competent, do things your professional peers would deem reasonable.
While I can commiserate with the author's feelings and dispute some of his observations, as others already did, I want to make an orthogonal observation.
Software development differs from other engineering disciplines dramatically: a blueprint/spec for a car or a bridge or a building is not in the same ontological category as a car or a bridge or a building: you cannot drive it or live in it.
However, a spec for a computer program is a kind of a program. It just requires "a truly smart compiler" (an SDE). This conceptual connection might explain the shape of the learning curve for software vs other engineering disciplines.
Software development differs from other engineering disciplines dramatically: a blueprint/spec for a car or a bridge or a building is not in the same ontological category as a car or a bridge or a building: you cannot drive it or live in it.
However, a spec for a computer program is a kind of a program. It just requires "a truly smart compiler" (an SDE). This conceptual connection might explain the shape of the learning curve for software vs other engineering disciplines.
I won’t ever forget a macroeconomics lecture I had back in university.
It was in line with “To accumulate wealth, you either have to exploit the planet, other nations or it’s own people. This applies for countries, companies and even individuals.”
It was in line with “To accumulate wealth, you either have to exploit the planet, other nations or it’s own people. This applies for countries, companies and even individuals.”
> To accumulate wealth, you either have to exploit the planet, other nations or it’s own people. This applies for countries, companies and even individuals.
That's an excellent way to put it.
Our regional Dental Surgeon association constantly runs ads encouraging people to become dental hygienist, explaining that it is a great career. It's obvious through why the association wants more hygienists - Dental office needs to hire and pay for Dental hygienists, which are owned by Dental Surgeons.
These days, tech companies and executives constantly encourage people to learn to code because it is supposed to be a great career. I couldn't think of other reasons beyond the obvious altruistic reason of just wanting to make everyone better off by guiding them towards this career. /s
Really, the issue is that many young people in software hadn't taken many social science or business courses so they hadn't seen how society/politics/business work until later in their career.
That's an excellent way to put it.
Our regional Dental Surgeon association constantly runs ads encouraging people to become dental hygienist, explaining that it is a great career. It's obvious through why the association wants more hygienists - Dental office needs to hire and pay for Dental hygienists, which are owned by Dental Surgeons.
These days, tech companies and executives constantly encourage people to learn to code because it is supposed to be a great career. I couldn't think of other reasons beyond the obvious altruistic reason of just wanting to make everyone better off by guiding them towards this career. /s
Really, the issue is that many young people in software hadn't taken many social science or business courses so they hadn't seen how society/politics/business work until later in their career.
Other fields effectively also rely on unpaid volunteers. Anything driven by academic research, say medical sciences, overwhelmingly relies on unpaid volunteer peer reviewers. Also the academics producing said papers in the first place... not unpaid (hmm) but also often not really qualified or outright fraudulent.
Still, it’s scary that to wield a pneumatic drill you need a license, but to suck in my personal data and store it on an unsecured S3 bucket you need absolutely nothing. To sign off a building you need a qualified surveyor, but medical records storage isn’t audited. Etc etc
Still, it’s scary that to wield a pneumatic drill you need a license, but to suck in my personal data and store it on an unsecured S3 bucket you need absolutely nothing. To sign off a building you need a qualified surveyor, but medical records storage isn’t audited. Etc etc
We use software that's developed voluntarily by unpaid developers because it's so much easier than trying to get permission to buy everything we need, so much more flexible and it takes the decision out of the hands of the managers who would screw it up for endless reasons that have nothing to do with what's the best tool for the job.
Software developers are in shortage and we don't need to put any more roadblocks in the way of people who decide to learn it. On the absolute contrary we need to make it easier.
Software developers are in shortage and we don't need to put any more roadblocks in the way of people who decide to learn it. On the absolute contrary we need to make it easier.
I can't read this article as anything other than "I want to be special, look at me".
The only thing worse than the idea is how poorly it's argued.
Boeing's issues are not software related. Those planes crashed because of MacDonald Douglas's involvement and the lack of accountability _for management_ that followed. Also the FAA. Licensed software engineers wouldn't have fixed a systemic issue elsewhere. Plainly a stupid, irresponsible and irreverent opinion.
Hopefully the author reneges on this nonsensical idea.
The only thing worse than the idea is how poorly it's argued.
Boeing's issues are not software related. Those planes crashed because of MacDonald Douglas's involvement and the lack of accountability _for management_ that followed. Also the FAA. Licensed software engineers wouldn't have fixed a systemic issue elsewhere. Plainly a stupid, irresponsible and irreverent opinion.
Hopefully the author reneges on this nonsensical idea.
Yes surely most workers the medical industry, most service workers, home health aids, school teachers, retail professionals, etc etc etc would be astonished and disappointed by the degree to which software engineering is trivialized in our society and professional landscape.
If you’re wondering why people think software developers are seen as out of touch children, I don’t think professional licensure is high on the list tbh.
If you’re wondering why people think software developers are seen as out of touch children, I don’t think professional licensure is high on the list tbh.
Man, to think the pioneers of our craft were free thinkers with liberty on their minds. We could so easily have had our field founded by obsessive credentialists.
Can you imagine? “Please enter your license number and authorization code to use this compiler”.
No thanks, credentialists. I’m a better programmer than you. And part of that is because I don’t waste time trying to become an MSCE or whatever you’re trying to do.
Can you imagine? “Please enter your license number and authorization code to use this compiler”.
No thanks, credentialists. I’m a better programmer than you. And part of that is because I don’t waste time trying to become an MSCE or whatever you’re trying to do.
Yet everyone runs around with their hair on fire chasing AWS certs. I'm missing your point.
I know many $1M+/year engineers. I know zero AWS certified $1M+/year engineers.
The point isn't to abolish the certification mechanism. It's to prevent it from being compulsory. The certification mechanism is a way for people without anything to recommend them to find a credential.
The point isn't to abolish the certification mechanism. It's to prevent it from being compulsory. The certification mechanism is a way for people without anything to recommend them to find a credential.
And looking for AI/ML specialists, and data scientists, with PhDs. How about that.
[deleted]
Reminds me of this[1] article, which instead is a rant about the lack of quality work in our industry.
[1] https://tonsky.me/blog/disenchantment/
You have it backwards. We need more engineers, less moats, less licensing, less credentials.
We have no idea how to even hire people. Think of all the tests, schemes and exercises we come up with and argue about in the context of hiring.
Now imagine some busybody picks one and mandates it, legally, across the entire industry.
What a nuisance. Shoo!
Now imagine some busybody picks one and mandates it, legally, across the entire industry.
What a nuisance. Shoo!
[deleted]
Odd to put this forward for a profession that pays 150 - 500K with a 1-4 years training. And software one of the fastest growing and most innovative parts of the economy. Breaking that seems bad, right?
It would be quite a bit better if most other industries eliminated licensing.
Because they become grab bags for random political whims that have nothing to do with ability to do the job:
https://www.nelp.org/publication/unlicensed-untapped-removin...
https://www.cato.org/policy-report/september/october-2018/ta...
Because they force workers to do hundreds of hours of unnecessary and expensive training:
https://nsjonline.com/article/2021/10/instructors-salon-owne...
Most of all we don't have any examples of nimble adaptable licensing, software development would not be some magical exception. For low innovation professions, where the knowledge doesn't change much over 20 years, licensing is bad. For a high innovation profession it would be crippling. What if when switching from Java to Python to Javascript you had to do 400 hours of training and sit for 2 days of tests each time? What if each of those transitions had taken industry an extra year to make because of excess oddball training requirements? What if certain members of your team couldn't "get up to speed" by being mentored on some system, but first had to be licensed before they could commit any code at all?
Far better for other occupations to copy our very successful one.
And as life advice, avoid any profession that does require licensing, it is usually a bad deal.
It would be quite a bit better if most other industries eliminated licensing.
Because they become grab bags for random political whims that have nothing to do with ability to do the job:
https://www.nelp.org/publication/unlicensed-untapped-removin...
https://www.cato.org/policy-report/september/october-2018/ta...
Because they force workers to do hundreds of hours of unnecessary and expensive training:
https://nsjonline.com/article/2021/10/instructors-salon-owne...
Most of all we don't have any examples of nimble adaptable licensing, software development would not be some magical exception. For low innovation professions, where the knowledge doesn't change much over 20 years, licensing is bad. For a high innovation profession it would be crippling. What if when switching from Java to Python to Javascript you had to do 400 hours of training and sit for 2 days of tests each time? What if each of those transitions had taken industry an extra year to make because of excess oddball training requirements? What if certain members of your team couldn't "get up to speed" by being mentored on some system, but first had to be licensed before they could commit any code at all?
Far better for other occupations to copy our very successful one.
And as life advice, avoid any profession that does require licensing, it is usually a bad deal.
Licensing will mostly allow mediocre developers in.
Anyone who does app security via a static bullet point list is bound to produce a sieve. And licensing is usually a series of bullet point lists.
Anyone who does app security via a static bullet point list is bound to produce a sieve. And licensing is usually a series of bullet point lists.
That’s the problem; I don’t want or need excellent developers, I need a known quality of developer.
I’m so sick of giving basic FizzBuzz and watching people with “10 years” of experience fail. I’m sure the competent developers want to stop wasting their time taking FizzBuzz!
We’re looking for a floor, not a ceiling.
I’m so sick of giving basic FizzBuzz and watching people with “10 years” of experience fail. I’m sure the competent developers want to stop wasting their time taking FizzBuzz!
We’re looking for a floor, not a ceiling.
I am curious. What is the ratio between the failure modes? E.g.
* Completely freezing / not coming up with any way to approach the problem / admitting they don't know how to code?
* Failing to use the basic tools, i.e. keyboard, text editor, compiler (please don't say you do whiteboarding)?
* Failing to produce code that compiles?
* Failing to produce an implementation that even approximates correct behavior?
* Failing at minor details / edge cases / reading comprehension?
* Failing at providing an unit test?
* Failing at code quality even if their solution works?
* Failing at explaining their solution?
* Completely freezing / not coming up with any way to approach the problem / admitting they don't know how to code?
* Failing to use the basic tools, i.e. keyboard, text editor, compiler (please don't say you do whiteboarding)?
* Failing to produce code that compiles?
* Failing to produce an implementation that even approximates correct behavior?
* Failing at minor details / edge cases / reading comprehension?
* Failing at providing an unit test?
* Failing at code quality even if their solution works?
* Failing at explaining their solution?
For my limited experience, and drawing only on memory of observation, rather than any recorded data, I'd break it down approximately as:
* 1/3rd of interviewees freeze up and wouldn't be able to add two numbers together if asked. This is, to me, is mostly indistinguishable from, "have never coded in their life and lied successfully to get this far."
* 1/3rd only partially freeze up and produce an incomplete solution and can't talk their way through what they did and why there's a missing piece
* 1/3rd are able to get through FizzBuzz but with great frustration (they're usually upset with themselves for struggling so much).
None of these failures are acceptable in an engineer with any amount of experience, even though they're not all strictly speaking about ability to work with data structures and algorithms in a vacuum.
The thing is, software development is a team sport, and you have to come ready to play. If the goal was to find the person with the absolute best ability to take a set of static requirements and turn them into functioning code by themselves, this would not be a fantastic test. That is not, however, how nearly any software job actually works.
* 1/3rd of interviewees freeze up and wouldn't be able to add two numbers together if asked. This is, to me, is mostly indistinguishable from, "have never coded in their life and lied successfully to get this far."
* 1/3rd only partially freeze up and produce an incomplete solution and can't talk their way through what they did and why there's a missing piece
* 1/3rd are able to get through FizzBuzz but with great frustration (they're usually upset with themselves for struggling so much).
None of these failures are acceptable in an engineer with any amount of experience, even though they're not all strictly speaking about ability to work with data structures and algorithms in a vacuum.
The thing is, software development is a team sport, and you have to come ready to play. If the goal was to find the person with the absolute best ability to take a set of static requirements and turn them into functioning code by themselves, this would not be a fantastic test. That is not, however, how nearly any software job actually works.
What do you learn from giving them FizzBuzz and watching them fail?
The obvious; that I should not hire them for a given senior development position.
It’s remarkable to me how many people do fail. I get that there’s pressure, but a huge part of being a senior dev is overcoming that to lead.
It’s remarkable to me how many people do fail. I get that there’s pressure, but a huge part of being a senior dev is overcoming that to lead.
Do you literally mean FizzBuzz or is that a stand-in for tricky leetcode puzzles? The latter seems to be a thing that selects for people who like puzzles. I’m in that camp but I don’t think it’s a super important area of interest.
I literally mean FizzBuzz, it’s gobsmacking how these people get as far as they do.
That they're obviously not senior, or even mediocre?
I dont want licensing, but mediocre developers are in. Many guys get in initially on self confidence and super basic skills only. Some of them learn and grow over time, other not all that much.
> Anyone who does app security via a static bullet point list is bound to produce a sieve. And licensing is usually a series of bullet point lists.
It would be improvement over current "app security via ignoring it" approach.
> Anyone who does app security via a static bullet point list is bound to produce a sieve. And licensing is usually a series of bullet point lists.
It would be improvement over current "app security via ignoring it" approach.
This a very weird post. I feel like he got half way through, attempted to make some horrible analogy about a squirrel and shake shack, and then ended the post.
What was your point?
What was your point?
Comparing ALL software developers to builders or veterinarians isn’t fair. Veterinarians are continually holding animals’ lives in their hands. Builders almost invariably build things that can fall on their head and kill them—so a license is needed. If you just want to build a doll house, though, no one is going to require a license.
Software developers sometimes work on critical infrastructure—and licensing there does make sense. But requiring a license for me to build a silly web app seems like a classic example of what people complain about when they complain about unnecessary government regulation.
Software developers sometimes work on critical infrastructure—and licensing there does make sense. But requiring a license for me to build a silly web app seems like a classic example of what people complain about when they complain about unnecessary government regulation.
Regarding licensing, having a degree from a good university with good grades is already a pretty good "license".
Indeed, we should ban people from bad universities from competing for our jobs. We certainly wouldn’t want anybody who hasn’t graduated high school to be working with us. They might say the wrong things or have the wrong attitudes.
It's not software engineering that needs licensing, but their managers. They need to listen to their engineers when they say that refactoring is needed, instead of "this cost money now and doesn't earn me more money now, so request declined".
Yes, "shipping is a feature", but "it compiles" is not enough to just "ship it": you need to spend serious time to test it.
I'm sure you all can come up with more examples
Yes, "shipping is a feature", but "it compiles" is not enough to just "ship it": you need to spend serious time to test it.
I'm sure you all can come up with more examples
Oh goodie, we're doing professional credentialing. First, you grandfather in all the people who are already working. Next, you artificially limit the people who can come in behind them so that the rates of the licensed pros can skyrocket. It works for surgeons and orthodontists, after all.
Count me in!
To author: The scroll performance of this webpage is bad on my mobile phone.
What do you know, the parts of the software profession where it really matters if someone does a good job do have qualifications and certification (network security, for instance).
When you build a shitty website, generally no one really gets hurt.
When you build a shitty website, generally no one really gets hurt.
If this blog post had been written 4000 years ago, it might have said:
I asked the other scribe at the temple if anyone can learn to read, and here's the first result:
Anyone can be literate — it's not magic. You don't need to be a pharaoh or a priest to solve writing problems in the real world
No other profession that I'm aware of trivializes their profession to the degrees that scribes do. Scribes should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice reading and writing.
— ⁂ —
http://www.cs.cmu.edu/~Compose/bok_assessment.pdf
In May 1999 the ACM Council adopted a resolution both reaffirming ACM’s commitment to solving the software quality problem and also stating its opposition to licensing software engineers, on the grounds that licensing is premature and would be ineffective in addressing the software quality problem. ACM Council also affirmed its interest in developing a core body of knowledge for software engineering, which is often viewed as an appealing step toward improving software quality. Our committee was formed to study the existing software engineering body of knowledge efforts — including SWEBOK, with which ACM is involved through the joint IEEE CS/ACM Software Engineering Coordinating Committee (SWECC). Our charge was to determine the status, progress, and likely outcome of these efforts. This report documents our findings, our reasoning, and our conclusions.
Our study and analysis has led us to the conclusion that the current software engineering body of knowledge efforts, including SWEBOK, are at best unlikely to achieve a goal of critical importance to ACM: the ability to provide appropriate assurances of software quality for software systems of public interest. Although the body of knowledge efforts may possibly make progress towards other stated and unstated objectives, we believe that ACM’s continued participation in the SWEBOK effort will not further — and indeed, may distract from — efforts to improve software quality, especially for systems of public interest. It would be consistent with our analysis for the ACM Council to choose to withdraw ACM from further involvement with SWEBOK, largely because of the danger of pursuing a path that might well provide false assurances to the public. Furthermore, we are uncertain whether, at present, there exists any process to articulate a core body of knowledge in software engineering that will directly contribute to the solution of the software quality problem. At a minimum, a conceptually clear and generally accepted organizing principle is a necessary pre-condition to the effective articulation of such a software engineering body of knowledge. No compelling organizing principle exists at present, and we see no clear course of action that would be likely to lead to one in the next few years.
— ⁂ —
That's from 02000, but unfortunately the situation hasn't changed since then. The IEEE continued promulgating the SWEBOK, but it's nothing more than a bunch of snake-oil methodology salesmen seeking unearned credibility for their fake project-management panaceas. We do have a few pieces of software that may have achieved reasonable quality for "software systems of public interest", like seL4 and CompCert, but it's still an extremely fringe activity.
— ⁂ —
The bigger issue is that computers are now our exocortices; we've offloaded significant amounts of our thinking and communication onto them, as we did previously with inventions like books and clocks. Computers vastly extend our mental abilities. Without control over our computers—without the legal and practical ability to program them and to investigate what they are programmed to do—we in effect lose our freedom of speech, association, and thought. That power is far too dangerous to allow any guild or faction to monopolize it.
— ⁂ —
The closest I've seen to a well-thought-out professional ethical code for software development is https://www.gnu.org/gnu/manifesto.en.html, which motivated the development of much of the infrastructural software we rely on every day: GCC, glibc, bash, GNU grep, GNU xargs, etc. Its core value is giving end users control over their own computers; this is completely incompatible with Huntley's point of view, not to mention much of current industry practice. But its main problem is that it doesn't go nearly far enough, having been written too early to contemplate issues like DRM, IoT, the commercialization of the internet, spam, and centralized online identity providers.
I asked the other scribe at the temple if anyone can learn to read, and here's the first result:
Anyone can be literate — it's not magic. You don't need to be a pharaoh or a priest to solve writing problems in the real world
No other profession that I'm aware of trivializes their profession to the degrees that scribes do. Scribes should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice reading and writing.
— ⁂ —
http://www.cs.cmu.edu/~Compose/bok_assessment.pdf
In May 1999 the ACM Council adopted a resolution both reaffirming ACM’s commitment to solving the software quality problem and also stating its opposition to licensing software engineers, on the grounds that licensing is premature and would be ineffective in addressing the software quality problem. ACM Council also affirmed its interest in developing a core body of knowledge for software engineering, which is often viewed as an appealing step toward improving software quality. Our committee was formed to study the existing software engineering body of knowledge efforts — including SWEBOK, with which ACM is involved through the joint IEEE CS/ACM Software Engineering Coordinating Committee (SWECC). Our charge was to determine the status, progress, and likely outcome of these efforts. This report documents our findings, our reasoning, and our conclusions.
Our study and analysis has led us to the conclusion that the current software engineering body of knowledge efforts, including SWEBOK, are at best unlikely to achieve a goal of critical importance to ACM: the ability to provide appropriate assurances of software quality for software systems of public interest. Although the body of knowledge efforts may possibly make progress towards other stated and unstated objectives, we believe that ACM’s continued participation in the SWEBOK effort will not further — and indeed, may distract from — efforts to improve software quality, especially for systems of public interest. It would be consistent with our analysis for the ACM Council to choose to withdraw ACM from further involvement with SWEBOK, largely because of the danger of pursuing a path that might well provide false assurances to the public. Furthermore, we are uncertain whether, at present, there exists any process to articulate a core body of knowledge in software engineering that will directly contribute to the solution of the software quality problem. At a minimum, a conceptually clear and generally accepted organizing principle is a necessary pre-condition to the effective articulation of such a software engineering body of knowledge. No compelling organizing principle exists at present, and we see no clear course of action that would be likely to lead to one in the next few years.
— ⁂ —
That's from 02000, but unfortunately the situation hasn't changed since then. The IEEE continued promulgating the SWEBOK, but it's nothing more than a bunch of snake-oil methodology salesmen seeking unearned credibility for their fake project-management panaceas. We do have a few pieces of software that may have achieved reasonable quality for "software systems of public interest", like seL4 and CompCert, but it's still an extremely fringe activity.
— ⁂ —
The bigger issue is that computers are now our exocortices; we've offloaded significant amounts of our thinking and communication onto them, as we did previously with inventions like books and clocks. Computers vastly extend our mental abilities. Without control over our computers—without the legal and practical ability to program them and to investigate what they are programmed to do—we in effect lose our freedom of speech, association, and thought. That power is far too dangerous to allow any guild or faction to monopolize it.
— ⁂ —
The closest I've seen to a well-thought-out professional ethical code for software development is https://www.gnu.org/gnu/manifesto.en.html, which motivated the development of much of the infrastructural software we rely on every day: GCC, glibc, bash, GNU grep, GNU xargs, etc. Its core value is giving end users control over their own computers; this is completely incompatible with Huntley's point of view, not to mention much of current industry practice. But its main problem is that it doesn't go nearly far enough, having been written too early to contemplate issues like DRM, IoT, the commercialization of the internet, spam, and centralized online identity providers.
> Software practitioners should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice software engineering.
Nope. You're done.
Nope. You're done.
Exactly. At what point do we need licensing? Someone writing Excel scripts? VB scripts? Making their first game? Making their first website? The first paid opportunity in any of those? Some things might be _reasonably_ licensed (but still in debate), if you are making an automatic robotic heart surgeon... but pretty sure that as a whole is already in that category and taken care of in other, better ways.
It would kill creativity, exploration, and innovation of those who are unlicensed. You don't need a PhD to start on the path, and since software is as broad as every other industry and has many different approaches, it is futile to try to set boundaries and limit it.
Is someone who prefers strict functional programming not worthy of certification? The "certification" would tend to favor the current dominant styles, which would be enterprise-y procedural-ish stuff. I don't think that would be a boon to the state of the art or to progress.
It would kill creativity, exploration, and innovation of those who are unlicensed. You don't need a PhD to start on the path, and since software is as broad as every other industry and has many different approaches, it is futile to try to set boundaries and limit it.
Is someone who prefers strict functional programming not worthy of certification? The "certification" would tend to favor the current dominant styles, which would be enterprise-y procedural-ish stuff. I don't think that would be a boon to the state of the art or to progress.
Handling personal data, health data, or financial data, could be criteria used in licensing.
Codes would exist for safely handling them, just like building codes for safely building a structure.
And no the code wouldn’t include functional vs object oriented programming, just as a building code wouldn’t specify the building’s paint colour.
Codes would exist for safely handling them, just like building codes for safely building a structure.
And no the code wouldn’t include functional vs object oriented programming, just as a building code wouldn’t specify the building’s paint colour.
American healthcare is already such a closed market with horribly inefficient, protectionist regulations that literally squeeze the breath out of American industries and consumers. Any proposal that could increase costs for marginal benefit should be considered dead on arrival.
You seem to have the idea that we would make it illegal to write any kind of code if you were not a licensed professional. That's a pretty glaring strawman that you have already dismissed by bringing up autonomous robot heart surgery.
You pretty much start with the most important stuff, exactly as you suggested. That's what the market wants. See this history of engineering licensure (https://www.nspe.org/sites/default/files/resources/pdfs/pema...): It was originally enacted to stop lawyers and random people claiming to certify the design of huge infrastructure projects for dams and irrigation, where the consequences of failure would be flooding huge areas, causing immeasurable damage. For the same reasons, if you're building dams or nuclear power control systems etc today, I imagine you'd be looking for a similar licensing system. Maybe you would simply use the licensing systems that already exist.
The rest of your comment sounds a bit like "it is oppression of my creativity when I build bridges that are made out of four thousand spoons tied together with craft glue and the NTSB says I am largely to blame for it falling on a pedestrian". It is obvious this far into the discipline's history that some things are good ideas and some things aren't, and it is possible to say that if your new 6-week-coding-bootcamp hire doesn't know anything about password hashing you should not give them the job of rewriting the login page. Nobody cares if you write it in Haskell, nobody's trying to draft statewide RIIR legislation, and you are KIDDING yourself if you think that your rebellion against enterprise-y procedural-ish stuff is more important than not letting Russian hackers steal all of your users' sensitive data and sell them to others who will blackmail them for more cash.
The market forces are in favour of accrediting the people who work on systems that are important to avoiding pretty dramatic harms, and even death and destruction. People aren't dumb and will eventually wise up enough about the shoddy work that gets done to start suing engineers behind data breaches for negligence (more). You're here proving the article's point by not taking this profession seriously enough to see that even a limited licensing scheme could be warranted.
You pretty much start with the most important stuff, exactly as you suggested. That's what the market wants. See this history of engineering licensure (https://www.nspe.org/sites/default/files/resources/pdfs/pema...): It was originally enacted to stop lawyers and random people claiming to certify the design of huge infrastructure projects for dams and irrigation, where the consequences of failure would be flooding huge areas, causing immeasurable damage. For the same reasons, if you're building dams or nuclear power control systems etc today, I imagine you'd be looking for a similar licensing system. Maybe you would simply use the licensing systems that already exist.
The rest of your comment sounds a bit like "it is oppression of my creativity when I build bridges that are made out of four thousand spoons tied together with craft glue and the NTSB says I am largely to blame for it falling on a pedestrian". It is obvious this far into the discipline's history that some things are good ideas and some things aren't, and it is possible to say that if your new 6-week-coding-bootcamp hire doesn't know anything about password hashing you should not give them the job of rewriting the login page. Nobody cares if you write it in Haskell, nobody's trying to draft statewide RIIR legislation, and you are KIDDING yourself if you think that your rebellion against enterprise-y procedural-ish stuff is more important than not letting Russian hackers steal all of your users' sensitive data and sell them to others who will blackmail them for more cash.
The market forces are in favour of accrediting the people who work on systems that are important to avoiding pretty dramatic harms, and even death and destruction. People aren't dumb and will eventually wise up enough about the shoddy work that gets done to start suing engineers behind data breaches for negligence (more). You're here proving the article's point by not taking this profession seriously enough to see that even a limited licensing scheme could be warranted.
As probably the only person here who actually did make autonomous
remote heart surgery code (Ada), very early in my career as a novice,
I disagree with the idea of licensing _programmers_.
What is needed is licenses for those who _deploy_ software in critical applications. They should be audited to hell and back and face catastrophic liability for failure.
We already are moving there, creating a small number of well paid, highly skilled senior positions who have 40+ years in software and full ISO9000/27000. It's a chartered quality assurance role that overlaps cyber-security/safety and resilience engineering.
And we must remember, that despite construction work being regulated to the hilt, we still got the "cladding scandal" and Grenfell Tower fire in the UK. Software "safety inspection", where appropriate, must also be a thing.
What is needed is licenses for those who _deploy_ software in critical applications. They should be audited to hell and back and face catastrophic liability for failure.
We already are moving there, creating a small number of well paid, highly skilled senior positions who have 40+ years in software and full ISO9000/27000. It's a chartered quality assurance role that overlaps cyber-security/safety and resilience engineering.
And we must remember, that despite construction work being regulated to the hilt, we still got the "cladding scandal" and Grenfell Tower fire in the UK. Software "safety inspection", where appropriate, must also be a thing.
That's why engineers have tiered systems where a number of unlicensed people can do the work, but a licensed one has to sign off on the work. Proposing similar licensing schemes to those in civil engineering basically means "do that". Nobody's interested in restricting access to Vim and python.exe to only the most learned and wise. This is why I framed the discussion about password hashing as being about a senior getting what amounts to an intern to do incredibly sensitive work without oversight.
Something the article did poorly is its analogy between software engineers and solo tradespeople. That's the wrong end. There is very little danger in having solo software engineers working unlicensed; they're out there making Wordpress websites and apps that are also basically information websites. Solo tradespeople are doing electrical work that might start a fire and kill a family. There is a big difference at the low end and it is bad to compare those two classes of worker.
Something the article did poorly is its analogy between software engineers and solo tradespeople. That's the wrong end. There is very little danger in having solo software engineers working unlicensed; they're out there making Wordpress websites and apps that are also basically information websites. Solo tradespeople are doing electrical work that might start a fire and kill a family. There is a big difference at the low end and it is bad to compare those two classes of worker.
This is standard for all Engineering disciplines except software. It’s really not that foreign of a concept.
It's also why software can be built far faster and better while other engineering disciplines struggle to build a bridge or plane. The more red tape means only the largest of orgs can operate it because the politics involved guarantee they're the ones that get to make the rules for everyone.
> only the largest companies could compete
That is fundamentally untrue. In fact, regulations would even the playing field. Right now, anyone can get their Engineering degree, complete an apprenticeship, and open a firm. Regulations like Building and electrical codes protect the public, and certified civil and electrical engineers are certifiably competent enough to implement them. Once certified, everyone has the qualifications to bid for the same contracts.
That is fundamentally untrue. In fact, regulations would even the playing field. Right now, anyone can get their Engineering degree, complete an apprenticeship, and open a firm. Regulations like Building and electrical codes protect the public, and certified civil and electrical engineers are certifiably competent enough to implement them. Once certified, everyone has the qualifications to bid for the same contracts.
>Right now, anyone can get their Engineering degree, complete an apprenticeship, and open a firm.
Great, then we should see that. We don't, because that's not true. To "open a firm" with all that red tape requires a great deal of people, namely lawyers and other engineers. That's big money, and it looks bad in comparison to the larger company that, again, gets to set all the rules for you.
Certifications are junk. They're a belief system the same as religion. All anyone has to do to be an engineer is get a degree. Do you see how many people have advanced degrees and have nothing but air between their ears? Yeah, I wouldn't trust them to make a popsicle stick bridge.
The reason for all the certs, degrees and requirements is control from the largest of corps. They want to set the standard to prevent competition and convince people they are the safe and effective option. You can't compete unless you play their game.
Great, then we should see that. We don't, because that's not true. To "open a firm" with all that red tape requires a great deal of people, namely lawyers and other engineers. That's big money, and it looks bad in comparison to the larger company that, again, gets to set all the rules for you.
Certifications are junk. They're a belief system the same as religion. All anyone has to do to be an engineer is get a degree. Do you see how many people have advanced degrees and have nothing but air between their ears? Yeah, I wouldn't trust them to make a popsicle stick bridge.
The reason for all the certs, degrees and requirements is control from the largest of corps. They want to set the standard to prevent competition and convince people they are the safe and effective option. You can't compete unless you play their game.
> All anyone has to do to be an engineer is get a degree.
A PEng needs thousands of hours of work experience then need to write competency exams. Religion? What are you talking about?
A PEng needs thousands of hours of work experience then need to write competency exams. Religion? What are you talking about?
What do you mean by "struggle"? What does "better" mean in this context?
Software is intangible and has fewer requirements which obviously helps with speed but the normalized pace of output doesn't seem significantly different. Large and complex software products with equivalent real-world reliability also take a very long time.
Software is intangible and has fewer requirements which obviously helps with speed but the normalized pace of output doesn't seem significantly different. Large and complex software products with equivalent real-world reliability also take a very long time.
The fact that software has far fewer physical limitations than every other field of engineering probably has something to do with the relative speed of its development.
You are asserting that software is built far better than bridges and airplanes?
It's really not, though (at least in the US). In just about every engineering subdiscipline except Civil/Structural, you can rise arbitrarily high in your career with no formal licensure or certification beyond a university degree and work experience. Official licensure schemes do technically exist for other subdisciplines, such as Mechanical, but I'm really not sure why. I've never met anybody who bothered to get one.
Generally one does not start learning chemical engineering in one's garage with what's to hand.
But people can and do start learning on their bedroom computers, and it's to be encouraged. Such self-taught people can make very valuable contributions, especially when they engage with the wider community. Locking them and their output out "because engineering" is likely to be massively counterproductive.
Like as not, software is different.
But people can and do start learning on their bedroom computers, and it's to be encouraged. Such self-taught people can make very valuable contributions, especially when they engage with the wider community. Locking them and their output out "because engineering" is likely to be massively counterproductive.
Like as not, software is different.
That something is standard is not an argument that it is good or beneficial. In 1300 it was standard to teach literacy and Latin at the same time and the vernacular was mostly an afterthought. If you want to say that more people programming is bad and they need to be stopped explain why.
Software is not an engineering discipline. Doesn't matter that they don't know what to call us, we aren't engineers. More closely related to poets or painters in my book.
And sometimes, more akin to bureaucrats or plumbers.
And behold! They have killed thousands! Perhaps hundreds of thousands! And what have we done? Killed 12 in a Therac-25?
They should try being like us!
They should try being like us!
That's a... very selective reading of history. The Boeing 737 MAX crashes, for starters, are of far more recent memory.
The Boeing 737 MAX crashes were caused by faulty AoA sensors. A rather classic measure by these so-called "professional" engineers: make a broken device and then pass the buck. Does their certification process teach this? In any case, happy to split the difference and call it even.
Okay, how about you build a list of software that directly killed people and I'll build a list of non-software that directly killed people in 2021. Then whoever finds more people killed gets $10k from the other? We can agree to terms of what it means for software to kill and non-software to kill. Therac-25 is obvious software, Florida condo collapse is obviously hardware.
Okay, how about you build a list of software that directly killed people and I'll build a list of non-software that directly killed people in 2021. Then whoever finds more people killed gets $10k from the other? We can agree to terms of what it means for software to kill and non-software to kill. Therac-25 is obvious software, Florida condo collapse is obviously hardware.
The fact that non-software has the capacity to end more lives than software is inherent in one being less plugged into the real-world? Perhaps I should wire you $10k straightaway out of the gratitude that we do not exist in the world where Stanislav Petrov dutifully followed the erroneous computer readings from Soviet early detection systems, sparking global thermonuclear war. Would that be a sufficient kill count to your liking?
Besides, few pieces of non-engineering is responsible for massive data breaches that lead to massive indirect consequences, such as Equifax. Perhaps your obsession with death overlooks other consequences of poor software engineering like financial ones, such as Black Monday, 1987. Perhaps bad software kills fewer people because less software engineering is involved with real-world systems- though requiescat in pace to those lost to Tesla Autopilot accidents, or the unfortunate biker in Arizona struck by a self-driving Uber.
I am transparently moving the goalposts here because your presumption that fatalities are the only consequence of shoddy software engineering was fallacious to begin with. Pray I do not move them any further.
Besides, few pieces of non-engineering is responsible for massive data breaches that lead to massive indirect consequences, such as Equifax. Perhaps your obsession with death overlooks other consequences of poor software engineering like financial ones, such as Black Monday, 1987. Perhaps bad software kills fewer people because less software engineering is involved with real-world systems- though requiescat in pace to those lost to Tesla Autopilot accidents, or the unfortunate biker in Arizona struck by a self-driving Uber.
I am transparently moving the goalposts here because your presumption that fatalities are the only consequence of shoddy software engineering was fallacious to begin with. Pray I do not move them any further.
Not standard at all. 10-20% of American engineers have a license.
Even after your comment I was willing to give the linked article the benefit of the doubt, then I came to this, 'If I type "Anyone can be a software developer" into Google here's the first result...'. Immediately after that he makes a declaration about the profession of "software engineering".
Either the writer doesn't understand the importance of words or they aren't being intellectually honest. Replacing his query with, "Anyone can be a software engineer". The first result I get is from Quora and there is a whole range of responses.
I do think there is a more nuanced argument to be made that some types of software engineering, may need regulation (air traffic control, medical devices, cars, planes, nuclear power plants) to the extent it doesn't have it already, but I don't think this article is being thoughtful enough to make it.
Either the writer doesn't understand the importance of words or they aren't being intellectually honest. Replacing his query with, "Anyone can be a software engineer". The first result I get is from Quora and there is a whole range of responses.
I do think there is a more nuanced argument to be made that some types of software engineering, may need regulation (air traffic control, medical devices, cars, planes, nuclear power plants) to the extent it doesn't have it already, but I don't think this article is being thoughtful enough to make it.
The most complex systems in the world are software. The automation behind software is staggering, absolutely mind-blowing. The amount of lives that depend on software in one way or another - from traffic lights to medical equipment would shock most people.
All this without licenses.
Ethical code? You mean laws?
How would you enforce this? Wipe compilers from one’s computer? Interpreters? Remove shells?
All this without licenses.
Ethical code? You mean laws?
How would you enforce this? Wipe compilers from one’s computer? Interpreters? Remove shells?
At one moment, he's crying about how widespread software like log4j has no corporate sponsors, and the next he's claiming that it should be illegal to write or use such software if it's not built by a megacorp with licensed engineers.
You can't have it both ways.
You can't have it both ways.
[deleted]
First off, most people would disagree in the first place whether coding is a „craft“, a science or even an art. He‘s saying craft (which is taught by other craftsmen), but what he probably means with his certification is college/uni.
Now I‘ve seen some of the worst sins of coding ever done by CompSci „master crafters“, with PhDs producing the cherries on the cake, with Java classes having longer names than the 80 character line limit.
And I don‘t even mean the designed-by-engineers frontends with UX level „crime against humanity“ (hello, early Hadoop).
I mean actual backends where CompSci education should shine, but even very smart people don‘t grasp the inherent cumulated complexity of massive systems. Because creating complexity is what you learn at Uni, rarely removing it.
Log4J wasn‘t a bug. It wasn‘t a backdoor. It was working as specified.
Look, this stuff is hard, one way or the other. I don‘t think we need even more gatekeeping and cover-your-ass to keep out the smart people who fail at university because they challenge the status quo and an outdated curriculum.