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.
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.
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...
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.
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.
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.
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.
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?
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).
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.
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.
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.
> 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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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?
>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
> 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.
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.
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.
[+] [-] endymi0n|4 years ago|reply
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.
[+] [-] tinco|4 years ago|reply
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.
[+] [-] bee_rider|4 years ago|reply
[+] [-] einherjae|4 years ago|reply
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.
[+] [-] SamReidHughes|4 years ago|reply
[+] [-] coldtea|4 years ago|reply
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".
[+] [-] bakuninsbart|4 years ago|reply
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.
[+] [-] dataflow|4 years ago|reply
[+] [-] manigandham|4 years ago|reply
[+] [-] onion2k|4 years ago|reply
[+] [-] atoav|4 years ago|reply
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?
[+] [-] dataflow|4 years ago|reply
[+] [-] jusssi|4 years ago|reply
[+] [-] Bancakes|4 years ago|reply
[+] [-] unicornmama|4 years ago|reply
Nsfw ortho meme: https://images.app.goo.gl/fTKFFYP9vTgoFiAs6
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] EnKopVand|4 years ago|reply
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.
[+] [-] Lukas_Skywalker|4 years ago|reply
[+] [-] Nursie|4 years ago|reply
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.
[+] [-] fy20|4 years ago|reply
[+] [-] cinntaile|4 years ago|reply
A tram
[+] [-] rickmode|4 years ago|reply
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.
[+] [-] Dracophoenix|4 years ago|reply
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.
[+] [-] zaptheimpaler|4 years ago|reply
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.
[+] [-] erosenbe0|4 years ago|reply
[+] [-] cush|4 years ago|reply
There’s absolutely no reason why software couldn’t have similar regulations and certifications for software sold to customers that carries liability.
[+] [-] wakeupcall|4 years ago|reply
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.
[+] [-] robbrown451|4 years ago|reply
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.
[+] [-] Lascaille|4 years ago|reply
I always view these pushes with a lot of suspicion given the nature of the people that tend to promote them.
[+] [-] paganel|4 years ago|reply
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.
[+] [-] injidup|4 years ago|reply
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.
[+] [-] someweirdperson|4 years ago|reply
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.
[+] [-] morelisp|4 years ago|reply
[+] [-] Tepix|4 years ago|reply
If a Lunar Lander were to be on Mars, is only software to blame? /s
[+] [-] eterevsky|4 years ago|reply
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.
[+] [-] cloudsec9|4 years ago|reply
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.
[+] [-] amelius|4 years ago|reply
This also holds for doctors.
[+] [-] dalbasal|4 years ago|reply
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.
[+] [-] twowatches|4 years ago|reply
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?
[+] [-] ChuckNorris89|4 years ago|reply
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
[+] [-] niemenmaa|4 years ago|reply
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.
[+] [-] Kim_Bruning|4 years ago|reply
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.
[+] [-] Apocryphon|4 years ago|reply
[+] [-] teddyh|4 years ago|reply
[+] [-] _Nat_|4 years ago|reply
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.
[+] [-] unicornmama|4 years ago|reply
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.
[+] [-] roenxi|4 years ago|reply
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.