5 ms·

That's definitely a very spicy take but I think people need to be more willing to engage with the idea. There is a serious problem where software engineers are

That's definitely a very spicy take but I think people need to be more willing to engage with the idea. There is a serious problem where software engineers are building systems that, when built poorly, are causing significant harm. If we don't engage with that problem we're going to get regulated in a way that we may not like. edit: Look at how many comments are just attacking a straw man policy. This is why we're going to end up getting regulated in some dumb way - people can't or won't even imagine a situation better than this one.

ryandrake 3y ago
This is one of the few opinions which are consistently rejected by the HN peanut gallery, unsurprisingly since most of us are developers. OP is brave to outright say it! Any time you bring up the idea of accountability to “engineers” for defects in their software that cause serious, real life harm, you get a litany of excuses in response, instead of good faith debate. If an engineer signs off on a bridge and it collapses, injuring a dozen people, there will at the very least be questions asked, if not more accountability. But if a software engineer implements a shoddy system that gets hacked and results in this kind of very personal data getting exfiltrated, all you get is 1,000 versions of “it’s not the developers’ fault!” and “they were probably under an impossible deadline!” And “bad manager told them what to implement, they had no choice!” and “the market forces this, careful developers can’t compete!” and so on. Saying there should be licensure with revocation as a consequence in extreme cases? Now that’s crazy-talk here!
- zer8k 3y ago
  Your opinion is admirable but you're missing something. I, as a software engineer, sign nothing. I do not have a license, I do not have a labor union, and I do not have the "professional stature" to tell my boss to fuck off when he suggests something dangerous. The reason engineering disciplines have such benefits is because after enough cars crumbled and bridges fell the leaders in the industry conceded they needed to listen to professionals. I hear similar bad faith arguments like "you can always quit!" or "your job is to write good code!". I can't always quit because I just got done being jobless for 3 months interviewing. My job was never to write good code. It was to deliver something on budget. If it so happens I get the time to write good, safe, code it was either an accident by management or something I did on my spare time. If you think this is a "bad faith" argument for software engineers being unlicensed you have never worked in the industry outside of high speed military stuff. I have no stake in the code I write because the code I write means nothing. I have no one to defend me and nothing to fall back on that qualifies me as an expert that can tell a VP of engineering to fuck off. Software engineering is an over-educated phrase for the new factory worker. We don't send factory workers to the brig for screwing up a widget. Neither will we send software engineers. If you want to change that it begins at the top. You need a labor union and/or an accreditation board backed by the largest companies guiding the industry. For that, I say, good luck. There's no fundamental physics of software engineering. There's no "basic safety" in software engineering. There are N languages and N+1 ways to blow your own foot off. Standardization would not be well received because the language itself would need to be blessed. This works well for the military who likely still runs a copy of GCC from 1992. It does not work for an industry evolving by the day. What does a PE look like in software engineering? What language? What planning framework? What compiler? This isn't even beginning to talk about contending with the fact a licensing scheme would send every H1B in America home and crush companies like InfoSys overnight. There's a lot of capital in just these two places to fight the licensing battle for several generations. Conflating engineering with software is a hazard. Software "engineers" are just laborers. Very well paid, but fundamentally no different than the guy who built your house. You may be able to argue language designers, software architects, etc would need to be "licensed" but the actual people writing the code are digital welders, house builders, and painters. These people are bonded but not licensed (usually). Companies implicitly bond their software engineers by eating the N million dollar cost of a mistake.
  - ryandrake 3y ago
    > I, as a software engineer, sign nothing. I do not have a license, I do not have a labor union, and I do not have the "professional stature" to tell my boss to fuck off when he suggests something dangerous. I think that's the original-OP's call to action: Our industry should set up this licensure/accountability infrastructure. Software Engineers should sign off that their creations will not cause harm. They should have a license they can point to when the V.P. tells them to ship harmful software. They should have a strong union behind them to give teeth to their ethical position. Software Engineering is decades old and full of very capable professionals. We should be working to set up the mechanisms of "professional stature" similar to what allows other licensed engineers to seriously push back against doing harm.
    - zer8k 3y ago
      This doesn't answer any of the questions I asked. 1. What language will be blessed? 2. What compiler will be blessed? 3. What does a PE look like? 4. What does pay look like after bonding and licensing? 5. What do we do about H1Bs and foreign contractors? 6. How do you fight the, likely, trillions in capital that will be deployed from companies that contract engineers? 7. How do you fight the billions of dollars invested into agile project management? 8. What do we do with software written outside the country? Even if it's written by someone licensed in their country? 9. How long does adoption of new software take? There have already been several failed attempts at licensing and achieving a PE status for software. It occasionally makes the news in IEEE. None of them have worked because none of them address these points. Worse, the ivory tower "we should seriously think about this" people address even fewer points than the organizations that failed. This battle has been fought and lost numerous times. I think the pro-licensing crowd forgets that licensing implies there will be exactly one (maybe two) blessed languages. It may even mean one or two blessed editors, one blessed UML software, one blessed planning framework (waterfall), etc. The language will either be C++ or Java and that will be how we code for the duration of the licensing scheme. Don't believe it will be either C++ or Java? Well, simply ask what your government uses.
      - insanitybit 3y ago
- deleted 3y ago
  [deleted]
- zirgs 3y ago
  What if an engineer designs a lock and someone picks it? What if an engineer designs a bridge that someone later destroys by finding a weak point and placing explosives there?
  - ryandrake 3y ago
    Root cause analysis with findings made public. What exactly was signed off, in what context, what was the failure and was it a design defect? If it was a design defect, what action could have prevented it? Did the engineer sign off that the action was conducted? Was the defect known at the time of shipping? I personally don't think it's fair to hold people accountable to unknown defects, as long as corrective action happens when they become known. You could limit accountability to known defects and still find lots of serious problems. We all know that our companies ship software with known defects all the time! I like how it works in aviation: Any time something happens, the NTSB swoops in and does a report and publishes their findings so everyone can learn from them. They list primary and contributing causes. If negligence or violations of FAR are found, then the FAA may start down the path of certificate suspension/revocation. Software is not as serious or deadly as aviation, so you wouldn't take it that far, but I'd say it's directionally where we should be going. Baby steps...
- Aurornis 3y ago
  The bigger flaw in your argument is assuming that imposing strict regulations on developers in your own country would have magically prevented this software breach from engineers and a company in a foreign country. I’m perplexed by how many people will see stories about companies having problems in foreign markets and conclude that we need to make things harder for ourselves domestically. Programmers are more fungible than your local licensed doctor or your local licensed PE structural engineer.
  - insanitybit 3y ago
    > The bigger flaw in your argument is assuming that imposing strict regulations on developers in your own country would have magically prevented this software breach from engineers and a company in a foreign country. Foreign companies care about complying with US policy when they sell to the US. It's not that complicated and I've said this repeatedly. Beyond that, one does not need an incredible imagination to think "how would these problems look domestically" so I don't know why so many people are hyperfocused on one problem existing in one country. It's not like the US doesn't see massive breaches constantly.
- mindslight 3y ago
  Professional ethics generally apply to representing the interest of your clients, not their victims. Engineering ethics and professional licensure don't discourage creating new weapons systems (eg armed drones) or more unnecessary prisons. Which means that for the main problem we're facing - big tech surveillance panopticon - widely understood engineering ethics has basically nothing to say! I wish this were different, but it's not. There's also the practical problem that this software wasn't even produced in the US. So then also ban the importation of any software that wasn't produced under a similar regime? So no, the idea that licensing software engineers could correct the problems of our industry seems wholly untenable and ultimately from the same broken-political vein of finding some fall guy to blame rather than directly regulating the behavior of malevolent companies.
- Kamq 3y ago
  > Any time you bring up the idea of accountability to “engineers” for defects in their software that cause serious, real life harm, you get a litany of excuses in response I'm generally against it, because I don't trust anyone to regulate this in a sane manner, but I'm open to discussion. If we're going have engineers sign off on things and be legally liable, there has to be a context that you're signing off on them to be used in as well. If a physical engineer signs off on a pedestrian bridge, and then people decide to drive semi-trucks over it, there's generally no liability for the original engineer. Same situation if an engineer signs off on a sturdy bridge, and someone makes a bunch of changes to materials without telling them. These seem roughly analogous to someone opening up something designed for private use to the open internet, and someone making changes to a function without telling the original engineer, respectively. These have to be excluded, or nobody can ever sign off on anything.
  - ryandrake 3y ago
    Yep, context and environment is important. You're signing off on your product being used in a particular context and in a particular environment. The semi-truck driving over a pedestrian bridge is a great example. Unfortunately for much of software engineering, our "environment" is the open Internet where there are largely invisible, international, adversarial attackers working 24 hours a day, seven days a week. With Internet-connected software we can't just say "Oh, this software's intended environment is a clean-room LAN with no connected devices! That's all I'm signing off." That's not reality. As for your example, companies should really, really have a hard conversation about taking a software designed for privacy use and just opening it up to the Internet without hardening it sufficiently. Accountability would help make that conversation possible.
    - JumpCrisscross 3y ago
      > semi-truck driving over a pedestrian bridge is a great example It also incentivises the engineer to clearly document their design’s limits. Imagine if software sales had that much transparency.
- nmz 3y ago
  I have never once written bugfree code. ever. I can mitigate with a myriad of tools, but sooner or later, a bug will popup. Nobody writes bugs on purpose, so of course the idea is ludicrous.
  - insanitybit 3y ago
    Only if you're unwilling to engage with the idea with anything more than a passing statement. No one is proposing that engineers be liable for every bug.
    - nmz 3y ago
      Can you control what the bug will be? There's a reason why OSS licenses revoke warranties.
      - insanitybit 3y ago
        I don't know what you're talking about wrt controlling what the bug will be but certifications already exist and they have nothing to do with bugs. Like SOC2.
ronsor 3y ago
I mean, the camera in question is from China. China is simply not going to care about any new regulation.
- insanitybit 3y ago
  China will care a lot about regulations in the US that prevent them from selling products to us. More so when the myriad US allies enforce similar laws, which the US can very trivially influence them to do. Anyway, my point isn't "we should regulate" or that "regulating will work". My point is that we need to start thinking much more seriously about our responsibilities because, if we don't, the government will do that thinking for us.
  - SV_BubbleTime 3y ago
    Importing products made from IP theft is illegal. How effective has that been? (Before you care to answer that, know that I have a product that has been ripped off in China. My code is put onto cloned devices, and you can buy them on Amazon right now. We’ve gone from reporting, to lawyers, to working with customs police in USA, Canada, China, and Europe. We’ve even had multiple state reps, and two US Senators (for both states we produce in) involved. Nothing is effective and China really really really doesn’t care.) Anyone that says “China will care if we just…” has little idea of this situation in my opinion.
    - insanitybit 3y ago
      I'm not saying that it would be the right way to go. I'm saying that other companies absolutely care about US policy. As for IP, this has increasingly led to tensions between the countries. To say that China doesn't care is silly, China cares and they spend a lot of effort making it viable to continue their practices.
      - SV_BubbleTime 3y ago
        >I'm saying that other companies absolutely care about US policy. Yea? Like Amazon and Walmart? It took a long time to get them to take our counterfeits down, and then only apply that to a vendor, so another pops up instantly. Here I am with first hand knowledge of the situation over years of difficulty and finally defeat, but your opinion is good too.
kodah 3y ago
I'd be supportive of licensing but it needs to go after the right things. Currently the industry is dominated by academics who took their CS & CE degrees and made them barriers to entry for jobs. Real software engineering involves very little DS&A. If we were making people demonstrate competency around OWASP on an infrastructure and dynamic application level I think licensure would go a long way.

ryandrake 3y ago

This is one of the few opinions which are consistently rejected by the HN peanut gallery, unsurprisingly since most of us are developers. OP is brave to outright say it! Any time you bring up the idea of accountability to “engineers” for defects in their software that cause serious, real life harm, you get a litany of excuses in response, instead of good faith debate. If an engineer signs off on a bridge and it collapses, injuring a dozen people, there will at the very least be questions asked, if not more accountability. But if a software engineer implements a shoddy system that gets hacked and results in this kind of very personal data getting exfiltrated, all you get is 1,000 versions of “it’s not the developers’ fault!” and “they were probably under an impossible deadline!” And “bad manager told them what to implement, they had no choice!” and “the market forces this, careful developers can’t compete!” and so on. Saying there should be licensure with revocation as a consequence in extreme cases? Now that’s crazy-talk here!

zer8k 3y ago
Your opinion is admirable but you're missing something. I, as a software engineer, sign nothing. I do not have a license, I do not have a labor union, and I do not have the "professional stature" to tell my boss to fuck off when he suggests something dangerous. The reason engineering disciplines have such benefits is because after enough cars crumbled and bridges fell the leaders in the industry conceded they needed to listen to professionals. I hear similar bad faith arguments like "you can always quit!" or "your job is to write good code!". I can't always quit because I just got done being jobless for 3 months interviewing. My job was never to write good code. It was to deliver something on budget. If it so happens I get the time to write good, safe, code it was either an accident by management or something I did on my spare time. If you think this is a "bad faith" argument for software engineers being unlicensed you have never worked in the industry outside of high speed military stuff. I have no stake in the code I write because the code I write means nothing. I have no one to defend me and nothing to fall back on that qualifies me as an expert that can tell a VP of engineering to fuck off. Software engineering is an over-educated phrase for the new factory worker. We don't send factory workers to the brig for screwing up a widget. Neither will we send software engineers. If you want to change that it begins at the top. You need a labor union and/or an accreditation board backed by the largest companies guiding the industry. For that, I say, good luck. There's no fundamental physics of software engineering. There's no "basic safety" in software engineering. There are N languages and N+1 ways to blow your own foot off. Standardization would not be well received because the language itself would need to be blessed. This works well for the military who likely still runs a copy of GCC from 1992. It does not work for an industry evolving by the day. What does a PE look like in software engineering? What language? What planning framework? What compiler? This isn't even beginning to talk about contending with the fact a licensing scheme would send every H1B in America home and crush companies like InfoSys overnight. There's a lot of capital in just these two places to fight the licensing battle for several generations. Conflating engineering with software is a hazard. Software "engineers" are just laborers. Very well paid, but fundamentally no different than the guy who built your house. You may be able to argue language designers, software architects, etc would need to be "licensed" but the actual people writing the code are digital welders, house builders, and painters. These people are bonded but not licensed (usually). Companies implicitly bond their software engineers by eating the N million dollar cost of a mistake.
- ryandrake 3y ago
  > I, as a software engineer, sign nothing. I do not have a license, I do not have a labor union, and I do not have the "professional stature" to tell my boss to fuck off when he suggests something dangerous. I think that's the original-OP's call to action: Our industry should set up this licensure/accountability infrastructure. Software Engineers should sign off that their creations will not cause harm. They should have a license they can point to when the V.P. tells them to ship harmful software. They should have a strong union behind them to give teeth to their ethical position. Software Engineering is decades old and full of very capable professionals. We should be working to set up the mechanisms of "professional stature" similar to what allows other licensed engineers to seriously push back against doing harm.
  - zer8k 3y ago
    This doesn't answer any of the questions I asked. 1. What language will be blessed? 2. What compiler will be blessed? 3. What does a PE look like? 4. What does pay look like after bonding and licensing? 5. What do we do about H1Bs and foreign contractors? 6. How do you fight the, likely, trillions in capital that will be deployed from companies that contract engineers? 7. How do you fight the billions of dollars invested into agile project management? 8. What do we do with software written outside the country? Even if it's written by someone licensed in their country? 9. How long does adoption of new software take? There have already been several failed attempts at licensing and achieving a PE status for software. It occasionally makes the news in IEEE. None of them have worked because none of them address these points. Worse, the ivory tower "we should seriously think about this" people address even fewer points than the organizations that failed. This battle has been fought and lost numerous times. I think the pro-licensing crowd forgets that licensing implies there will be exactly one (maybe two) blessed languages. It may even mean one or two blessed editors, one blessed UML software, one blessed planning framework (waterfall), etc. The language will either be C++ or Java and that will be how we code for the duration of the licensing scheme. Don't believe it will be either C++ or Java? Well, simply ask what your government uses.
    - insanitybit 3y ago
deleted 3y ago
[deleted]
zirgs 3y ago
What if an engineer designs a lock and someone picks it? What if an engineer designs a bridge that someone later destroys by finding a weak point and placing explosives there?
- ryandrake 3y ago
  Root cause analysis with findings made public. What exactly was signed off, in what context, what was the failure and was it a design defect? If it was a design defect, what action could have prevented it? Did the engineer sign off that the action was conducted? Was the defect known at the time of shipping? I personally don't think it's fair to hold people accountable to unknown defects, as long as corrective action happens when they become known. You could limit accountability to known defects and still find lots of serious problems. We all know that our companies ship software with known defects all the time! I like how it works in aviation: Any time something happens, the NTSB swoops in and does a report and publishes their findings so everyone can learn from them. They list primary and contributing causes. If negligence or violations of FAR are found, then the FAA may start down the path of certificate suspension/revocation. Software is not as serious or deadly as aviation, so you wouldn't take it that far, but I'd say it's directionally where we should be going. Baby steps...
Aurornis 3y ago
The bigger flaw in your argument is assuming that imposing strict regulations on developers in your own country would have magically prevented this software breach from engineers and a company in a foreign country. I’m perplexed by how many people will see stories about companies having problems in foreign markets and conclude that we need to make things harder for ourselves domestically. Programmers are more fungible than your local licensed doctor or your local licensed PE structural engineer.
- insanitybit 3y ago
  > The bigger flaw in your argument is assuming that imposing strict regulations on developers in your own country would have magically prevented this software breach from engineers and a company in a foreign country. Foreign companies care about complying with US policy when they sell to the US. It's not that complicated and I've said this repeatedly. Beyond that, one does not need an incredible imagination to think "how would these problems look domestically" so I don't know why so many people are hyperfocused on one problem existing in one country. It's not like the US doesn't see massive breaches constantly.
mindslight 3y ago
Professional ethics generally apply to representing the interest of your clients, not their victims. Engineering ethics and professional licensure don't discourage creating new weapons systems (eg armed drones) or more unnecessary prisons. Which means that for the main problem we're facing - big tech surveillance panopticon - widely understood engineering ethics has basically nothing to say! I wish this were different, but it's not. There's also the practical problem that this software wasn't even produced in the US. So then also ban the importation of any software that wasn't produced under a similar regime? So no, the idea that licensing software engineers could correct the problems of our industry seems wholly untenable and ultimately from the same broken-political vein of finding some fall guy to blame rather than directly regulating the behavior of malevolent companies.
Kamq 3y ago
> Any time you bring up the idea of accountability to “engineers” for defects in their software that cause serious, real life harm, you get a litany of excuses in response I'm generally against it, because I don't trust anyone to regulate this in a sane manner, but I'm open to discussion. If we're going have engineers sign off on things and be legally liable, there has to be a context that you're signing off on them to be used in as well. If a physical engineer signs off on a pedestrian bridge, and then people decide to drive semi-trucks over it, there's generally no liability for the original engineer. Same situation if an engineer signs off on a sturdy bridge, and someone makes a bunch of changes to materials without telling them. These seem roughly analogous to someone opening up something designed for private use to the open internet, and someone making changes to a function without telling the original engineer, respectively. These have to be excluded, or nobody can ever sign off on anything.
- ryandrake 3y ago
  Yep, context and environment is important. You're signing off on your product being used in a particular context and in a particular environment. The semi-truck driving over a pedestrian bridge is a great example. Unfortunately for much of software engineering, our "environment" is the open Internet where there are largely invisible, international, adversarial attackers working 24 hours a day, seven days a week. With Internet-connected software we can't just say "Oh, this software's intended environment is a clean-room LAN with no connected devices! That's all I'm signing off." That's not reality. As for your example, companies should really, really have a hard conversation about taking a software designed for privacy use and just opening it up to the Internet without hardening it sufficiently. Accountability would help make that conversation possible.
  - JumpCrisscross 3y ago
    > semi-truck driving over a pedestrian bridge is a great example It also incentivises the engineer to clearly document their design’s limits. Imagine if software sales had that much transparency.
nmz 3y ago
I have never once written bugfree code. ever. I can mitigate with a myriad of tools, but sooner or later, a bug will popup. Nobody writes bugs on purpose, so of course the idea is ludicrous.
- insanitybit 3y ago
  Only if you're unwilling to engage with the idea with anything more than a passing statement. No one is proposing that engineers be liable for every bug.
  - nmz 3y ago
    Can you control what the bug will be? There's a reason why OSS licenses revoke warranties.
    - insanitybit 3y ago
      I don't know what you're talking about wrt controlling what the bug will be but certifications already exist and they have nothing to do with bugs. Like SOC2.

ronsor 3y ago

I mean, the camera in question is from China. China is simply not going to care about any new regulation.

insanitybit 3y ago
China will care a lot about regulations in the US that prevent them from selling products to us. More so when the myriad US allies enforce similar laws, which the US can very trivially influence them to do. Anyway, my point isn't "we should regulate" or that "regulating will work". My point is that we need to start thinking much more seriously about our responsibilities because, if we don't, the government will do that thinking for us.
- SV_BubbleTime 3y ago
  Importing products made from IP theft is illegal. How effective has that been? (Before you care to answer that, know that I have a product that has been ripped off in China. My code is put onto cloned devices, and you can buy them on Amazon right now. We’ve gone from reporting, to lawyers, to working with customs police in USA, Canada, China, and Europe. We’ve even had multiple state reps, and two US Senators (for both states we produce in) involved. Nothing is effective and China really really really doesn’t care.) Anyone that says “China will care if we just…” has little idea of this situation in my opinion.
  - insanitybit 3y ago
    I'm not saying that it would be the right way to go. I'm saying that other companies absolutely care about US policy. As for IP, this has increasingly led to tensions between the countries. To say that China doesn't care is silly, China cares and they spend a lot of effort making it viable to continue their practices.
    - SV_BubbleTime 3y ago
      >I'm saying that other companies absolutely care about US policy. Yea? Like Amazon and Walmart? It took a long time to get them to take our counterfeits down, and then only apply that to a vendor, so another pops up instantly. Here I am with first hand knowledge of the situation over years of difficulty and finally defeat, but your opinion is good too.

kodah 3y ago

I'd be supportive of licensing but it needs to go after the right things. Currently the industry is dominated by academics who took their CS & CE degrees and made them barriers to entry for jobs. Real software engineering involves very little DS&A. If we were making people demonstrate competency around OWASP on an infrastructure and dynamic application level I think licensure would go a long way.