4 ms·

> Provide a legal mandate to punish companies that fail to adhere to specific levels of quality control. This is the only workable solution - fortunately it fi

> Provide a legal mandate to punish companies that fail to adhere to specific levels of quality control. This is the only workable solution - fortunately it fits right into established regulatory frameworks. ------------- Controversial opinion: I do think we need some kind of widely-recognized (i.e. not just in Texas) professional licensing system for SEs/SWEs to enable some kind of accountability for bad software products: ...When a building collapses and kills people, the civil engineer-of-record is accountable or serve as witness. Similarly when avionics software kills passengers (MCAS, etc) there should be a software-engineer-of-record to be held accountable or to serve as witness. Change my opinion. I know there's a big difference between safety-critical software systems and consumer-hostile inkjet printer cartridges ( https://news.ycombinator.com/item?id=28888214 https://news.ycombinator.com/item?id=28888214 ) - but more and more jurisdictions (especially outside the US) are going to call-out US and international software and hardware companies on their business-practices which means they'll probably institute something like this inevitably.

consumer451 5y ago
I agree with you. It is time. Code runs too much of our world to not have a formalized system of accountability. At least in some domains to start. One thing though, in the US, and in the case of a building, it would be a Structural Engineer not Civil. And specificity a PE, or Professional Engineer who has a personalized rubber stamp mark registered with the state. At least that’s what I recall from supporting a CAD department 25 years ago.
Gigachad 5y ago
The difference is that construction is largely doing the exact same thing that has been refined over thousands of years and we know very well how it goes and have formulas to precalculate everything. So you can have a set of building codes which if you follow, are very likely to produce a perfectly fine building. While software development is completely making things up as you go because it hasn’t ever been done before. Any kind of government regulation would end up as a box checking exercise that wouldn’t add any more safety and probably introduce problems when products have nonsensical decisions added in to fit with some requirements.
- blippage 5y ago
  I'll add that we expect software to work on highly heterogeneous systems, too. If you're working on a bridge, you known exactly the terrain you're required to span. The engineers battle with a lot of integration issues, but at least they know what they're dealing with. With software development, well, who's to say what integration issues that millions of people might face?
- wongarsu 5y ago
  On the other hand our ability to precalculate everything in construction seems to be fairly novel, in the sense that complex geometries are very hard to calculate without computer simulations. And most buildings we build today are nothing like those we built 200 years ago. The necessity of modelling building behaviour has pushed the field forwards. For software we know that modelling and verification works in principle, but little time is spent on improving the methods because there's no demand
- p2t2p 5y ago
  I counter that with that we’ve got methods of developing relyable software and we’ve got examples of success. We’ve got all sorts of different tiers of testing and verification, we’ve got various CI/CD approaches and NASA seems to be landing one rover after another and flying an freaking helicopter on a freaking another planet, autonomously. We’ve got the tools to explore unknowns. Now, as to regulation. It could be written in a way that would relieve that “developer-of-record” out of responcibility provided they did their due diligence and, if new unknown happened that wasn’t foreseen the regulations will adapt and change and make a learning out of it, just like it was with building industry and road rules.
  - DaiPlusPlus 5y ago
    > I counter that with that we’ve got methods of developing relyable software We don't have methods for reliable spelling, however...
    - p2t2p 5y ago
      My spelling is horrible, especially when I write on the phone, I know, sorry
nottorp 5y ago
> specific levels of quality control. Good luck defining that though. The main difference between programming and engineering is unfortunately that no one wants you to build the same thing over and over. So you have no idea if it will work until you build it. Please don't point me to formal correctness proofs, they just won't work at scale. Hmm, perhaps some bright mind will come with a proof that correctness proofs are too complex to be practical.
- throwaway81523 5y ago
  > The main difference between programming and engineering is unfortunately that no one wants you to build the same thing over and over. So you have no idea if it will work until you build it. In between there is the radical idea of writing code carefully, testing, and documenting it before shipping it. All of us as programmers want to do that, but we have all worked under management that insisted on the opposite.
  - nottorp 5y ago
    Define that too :) Budget restrictions aside. For some young things I'm working with, basic debugging techniques seem to be foreign as well...
- Seirdy 5y ago
  The CII Best Practices initiative sets a good set of requirements to qualify. Mission-critical software needs to have a good bus factor, keep its deps up to date, have guards in place for the OWASP Top 10 vulns and others (where appropriate), not lean heavily on badness enumeration, etc. We can set requirements for certain types of software to get certified for a level of reliability, taking inspiration from the CII Best Practices. Two ways to qualify for a certification can include testing and formal verification; I won't elaborate on the latter as per your request. Good statement coverage from tests is a necessary but absolutely insufficient requirement for tests; they need good branch coverage, and need to pass a good mutation score threshold. Property-based testing makes this a lot easier. Fuzz-testing is another good follow-up once these get checked off. Software that passes the above checks and more can qualify for manual review, looking for common vulns and warranted practices. Much of what I've brainstormed above applies to complex software; simple/small software is much more manageable and probably doesn't need to be held to such standards.
askvictor 5y ago
I generally agree with you, but where do you draw the line on what software needs this accountability? Particularly when things change pretty quickly in the field. As an example, 30 years ago, a lot of the internet was not 'important' yet it grew to critical for most of our systems.
russelldjimmy 5y ago
In my opinion, your comment and all the comments replying to it (as of writing this comment) are well-considered arguments with valid points. To summarise: - we need a licensing system because it promotes accountability and encourages companies to think long-term even when the short-term benefits are tantalising. - but everything we do in SWE is so new that any licensing system run the risk of (a) being too loose so as to be easily gamed or ignored (think cookie banners a la GDPR), or (b) being too labyrinthian that it kills innovation Being a product designer, I am directly affected by many of the same issues as engineers. I would be happy to indulge in some level-headed debate. I will be watching this thread so please reply if you have any insight to add! Thank you.
garren 5y ago
Is the Texas Software PE exam still there? I looked into it years ago out of curiosity, but now I’m seeing that it might not be around any more[0] > NCEES discontinued the PE Software exam after April 2019. I think the industry would benefit from an FE style exam at the very least. [0] https://ncees.org/engineering/pe/software/ https://ncees.org/engineering/pe/software/

consumer451 5y ago

I agree with you. It is time. Code runs too much of our world to not have a formalized system of accountability. At least in some domains to start. One thing though, in the US, and in the case of a building, it would be a Structural Engineer not Civil. And specificity a PE, or Professional Engineer who has a personalized rubber stamp mark registered with the state. At least that’s what I recall from supporting a CAD department 25 years ago.

Gigachad 5y ago

The difference is that construction is largely doing the exact same thing that has been refined over thousands of years and we know very well how it goes and have formulas to precalculate everything. So you can have a set of building codes which if you follow, are very likely to produce a perfectly fine building. While software development is completely making things up as you go because it hasn’t ever been done before. Any kind of government regulation would end up as a box checking exercise that wouldn’t add any more safety and probably introduce problems when products have nonsensical decisions added in to fit with some requirements.

blippage 5y ago
I'll add that we expect software to work on highly heterogeneous systems, too. If you're working on a bridge, you known exactly the terrain you're required to span. The engineers battle with a lot of integration issues, but at least they know what they're dealing with. With software development, well, who's to say what integration issues that millions of people might face?
wongarsu 5y ago
On the other hand our ability to precalculate everything in construction seems to be fairly novel, in the sense that complex geometries are very hard to calculate without computer simulations. And most buildings we build today are nothing like those we built 200 years ago. The necessity of modelling building behaviour has pushed the field forwards. For software we know that modelling and verification works in principle, but little time is spent on improving the methods because there's no demand
p2t2p 5y ago
I counter that with that we’ve got methods of developing relyable software and we’ve got examples of success. We’ve got all sorts of different tiers of testing and verification, we’ve got various CI/CD approaches and NASA seems to be landing one rover after another and flying an freaking helicopter on a freaking another planet, autonomously. We’ve got the tools to explore unknowns. Now, as to regulation. It could be written in a way that would relieve that “developer-of-record” out of responcibility provided they did their due diligence and, if new unknown happened that wasn’t foreseen the regulations will adapt and change and make a learning out of it, just like it was with building industry and road rules.
- DaiPlusPlus 5y ago
  > I counter that with that we’ve got methods of developing relyable software We don't have methods for reliable spelling, however...
  - p2t2p 5y ago
    My spelling is horrible, especially when I write on the phone, I know, sorry

nottorp 5y ago

> specific levels of quality control. Good luck defining that though. The main difference between programming and engineering is unfortunately that no one wants you to build the same thing over and over. So you have no idea if it will work until you build it. Please don't point me to formal correctness proofs, they just won't work at scale. Hmm, perhaps some bright mind will come with a proof that correctness proofs are too complex to be practical.

throwaway81523 5y ago
> The main difference between programming and engineering is unfortunately that no one wants you to build the same thing over and over. So you have no idea if it will work until you build it. In between there is the radical idea of writing code carefully, testing, and documenting it before shipping it. All of us as programmers want to do that, but we have all worked under management that insisted on the opposite.
- nottorp 5y ago
  Define that too :) Budget restrictions aside. For some young things I'm working with, basic debugging techniques seem to be foreign as well...
Seirdy 5y ago
The CII Best Practices initiative sets a good set of requirements to qualify. Mission-critical software needs to have a good bus factor, keep its deps up to date, have guards in place for the OWASP Top 10 vulns and others (where appropriate), not lean heavily on badness enumeration, etc. We can set requirements for certain types of software to get certified for a level of reliability, taking inspiration from the CII Best Practices. Two ways to qualify for a certification can include testing and formal verification; I won't elaborate on the latter as per your request. Good statement coverage from tests is a necessary but absolutely insufficient requirement for tests; they need good branch coverage, and need to pass a good mutation score threshold. Property-based testing makes this a lot easier. Fuzz-testing is another good follow-up once these get checked off. Software that passes the above checks and more can qualify for manual review, looking for common vulns and warranted practices. Much of what I've brainstormed above applies to complex software; simple/small software is much more manageable and probably doesn't need to be held to such standards.

askvictor 5y ago

I generally agree with you, but where do you draw the line on what software needs this accountability? Particularly when things change pretty quickly in the field. As an example, 30 years ago, a lot of the internet was not 'important' yet it grew to critical for most of our systems.

russelldjimmy 5y ago

In my opinion, your comment and all the comments replying to it (as of writing this comment) are well-considered arguments with valid points. To summarise: - we need a licensing system because it promotes accountability and encourages companies to think long-term even when the short-term benefits are tantalising. - but everything we do in SWE is so new that any licensing system run the risk of (a) being too loose so as to be easily gamed or ignored (think cookie banners a la GDPR), or (b) being too labyrinthian that it kills innovation Being a product designer, I am directly affected by many of the same issues as engineers. I would be happy to indulge in some level-headed debate. I will be watching this thread so please reply if you have any insight to add! Thank you.

garren 5y ago

Is the Texas Software PE exam still there? I looked into it years ago out of curiosity, but now I’m seeing that it might not be around any more[0] > NCEES discontinued the PE Software exam after April 2019. I think the industry would benefit from an FE style exam at the very least. [0] https://ncees.org/engineering/pe/software/ https://ncees.org/engineering/pe/software/