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.
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!
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
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
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.
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.
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.
>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?
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
> 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
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
205 comments
[ 4.9 ms ] story [ 244 ms ] threadAnyone 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.
It would be improvement over current "app security via ignoring it" approach.
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.
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.
* 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?
* 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.
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.
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.
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.
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 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.
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 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.
A tram
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.
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.
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.
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.
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.
That didn't work out so great for Boeing.
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.
(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.
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?
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
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.
I always view these pushes with a lot of suspicion given the nature of the people that tend to promote them.
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.
Nope. You're done.
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.
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.
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.
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.
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.
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.
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.
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.
A PEng needs thousands of hours of work experience then need to write competency exams. Religion? What are you talking about?
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.
They should try being like us!
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.
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.
All this without licenses.
Ethical code? You mean laws?
How would you enforce this? Wipe compilers from one’s computer? Interpreters? Remove shells?
You can't have it both ways.
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 "serious" qualifier makes this a "no true Scotsman".
If a developer thinks that, then one can always say "he is not a serious developer".
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.
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.
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.
Nothing would get done.
If a Lunar Lander were to be on Mars, is only software to blame? /s
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.
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.
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.
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.
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.
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.
This also holds for doctors.
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.
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.
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.
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.
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.
Nsfw ortho meme: https://images.app.goo.gl/fTKFFYP9vTgoFiAs6
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.
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?
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.
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.