5 ms·

> I don't want a car where someone can push safety critical changes the way we push shitty software updates now. I don't trust them to get it right. I don't wan

> I don't want a car where someone can push safety critical changes the way we push shitty software updates now. I don't trust them to get it right. I don't want to be sold a car that tries to kill me after a mandatory software update. It's not needed, and it's a bad idea. I don't want a bridge where someone can make repairs the way we make shitty pothole repairs now. I don't trust them to get it right. I don't want to pay taxes for a bridge that tries to kill me after mandatory repairs. It's not needed, and it's a bad idea. https://en.wikipedia.org/wiki/I-35W_Mississippi_River_bridge https://en.wikipedia.org/wiki/I-35W_Mississippi_River_bridge Here's a neat idea: maybe regulating software engineering like other engineering disciplines is actually overdue? Yet at the same time, failure rate will never be zero. Alternatively, we should renounce all engineering regulations and let anybody with a rivet gun build bridges. and airplanes.

thulecitizen 7y ago
> Here's a neat idea: maybe regulating software engineering like other engineering disciplines is actually overdue? Yet at the same time, failure rate will never be zero. Please could you describe this more? I’m intrigued. I don’t know anything about this and what systems or mechanisms are used to regulate engineering, so any links or simple explanations are appreciated!
- waste_monk 7y ago
  Overview of professional engineer process: https://www.nspe.org/resources/licensure/what-pe https://www.nspe.org/resources/licensure/what-pe . It varies from place to place (although transferrable from country to country via the Washington Accord https://www.ieagreements.org/accords/washington/ https://www.ieagreements.org/accords/washington/). If you want to e.g. build a bridge it needs to be signed off on by an appropriately licensed and qualified Professional Engineer. Essentially the parent comment is saying there should be streams of software development that meet the requirements to become a Professional Engineer. Then places e.g. medical, defence, power plants could say "we need software that's been signed off by an engineer" and have assurance that the final product is of a known quality and unlikely to have any life and safety endangering defects. They are strongly incentivised to only sign off on properly engineered projects as they can be held personally liable e.g. if a bridge fails and kills someone. An example of the level of quality that would be delivered is the software that ran on the space shuttle. See this article https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff for an insight into how it was developed and the practises required. I don't think all software developers should be software Engineers, but being able to lead a team to enforce quality (and not sign off on poorly thought out "MVP" crapware) would guarantee that the software that came out of that team would be reliable and well designed. It would be good for software engineering overall to be recognised as a legitimate branch of engineering. Unfortunately it seems like most of the industry does not have the sort of rigour needed for engineering tasks.
  - thulecitizen 7y ago
    Thanks a lot!
  - cr0sh 7y ago
    > It would be good for software engineering overall to be recognised as a legitimate branch of engineering. I think the only way this could happen would be if SWE only used waterfall or some similar kind of practice. Agile and the like might be able to be tweaked to work, but even there... The problem in software is that you can basically "start in the middle" of something and work your way outward; start coding something, get the design details later and refactor. You can't do that with a bridge or other regular engineering work. You have to plan, design, multiple sign-offs, etc - then build, and you can't build it randomly or a component here and there then fit it all together (well, you can to an extent, depending on the project and design), and if anything changes - well, in a real project it can't change much, not without a lot of money and time being lost. Several years back there was a series of commercials on TV, I think for an insurance company, which showed (using CGI effects) "impossible building strategies" - one showed a huge scaffolding structure and cranes building something like the Great Pyramid from the top downward (for instance); I think another had some kind of skyscraper being built from the middle outward or something of that nature. That's essentially SWE applied to regular engineering - or at least, that's how it feels at times. Now tack on Agile and other practices, and it gets 10x worse. Actual engineering is a strict discipline, starting with almost set-in-stone practices along with a lot of hard-won knowledge about materials and mechanics (books filled with tables and diagrams), that are then all used to inform an engineering design, which is then tested and retested in simulation, perhaps coupled with scale models that are also tested, and the plans changed and signed off by multiple other engineers, etc - long before it ever gets to building the thing. And then that thing is built in a very specific and strict manner; I won't further belabor the point. Even with all of this, sometimes things fail terribly. Today in software, we have a ton of tools and practices we are constantly trying - and despite all of them, at least from my perspective - things really haven't gotten much better than they were 20-30 years ago. I would say that widespread use of software versioning tooling and testing frameworks, etc (plus automated build and deployment) have made some of it better - but even after all that, we still seem to be making the same number of bugs and errors that we had before (and rather than a QA department usually, we've farmed this out to the end user for the most part). So while I'd love to see SWE become more like regular engineering practices (with the selfish request that I and others like me could be "grandfathered" in, as I don't have any kind of compsci or comparable degree, but I have been doing this for 25+ years) - I just don't see it happening for the above rational and reasons. I could be wrong, though (and if anyone has a counter argument, please post it - I'd love to read it)...
Stratoscope 7y ago
You may have some good points, but when you quote someone word for word, substituting your own words for some of theirs, you are twisting their words and putting words in their mouth, in essence ridiculing them. That rarely leads to a civil discussion that other people can learn from. I realize that this kind of misquoting is a traditional "hacker" style of debate. But speaking only for myself, it really rubs me the wrong way. If you disagree with someone, don't resort to cheap shots like that. Make your point in your own words and with your own logic. You will have a stronger argument and a better chance of informing and educating the rest of us.
imtringued 7y ago
This is a strawman. Why are you talking about public infrastructure in a submission about privately owned vehicles that are exclusively used on privately owned land that has no paved roads or any significant traffic?

thulecitizen 7y ago

> Here's a neat idea: maybe regulating software engineering like other engineering disciplines is actually overdue? Yet at the same time, failure rate will never be zero. Please could you describe this more? I’m intrigued. I don’t know anything about this and what systems or mechanisms are used to regulate engineering, so any links or simple explanations are appreciated!

waste_monk 7y ago
Overview of professional engineer process: https://www.nspe.org/resources/licensure/what-pe https://www.nspe.org/resources/licensure/what-pe . It varies from place to place (although transferrable from country to country via the Washington Accord https://www.ieagreements.org/accords/washington/ https://www.ieagreements.org/accords/washington/). If you want to e.g. build a bridge it needs to be signed off on by an appropriately licensed and qualified Professional Engineer. Essentially the parent comment is saying there should be streams of software development that meet the requirements to become a Professional Engineer. Then places e.g. medical, defence, power plants could say "we need software that's been signed off by an engineer" and have assurance that the final product is of a known quality and unlikely to have any life and safety endangering defects. They are strongly incentivised to only sign off on properly engineered projects as they can be held personally liable e.g. if a bridge fails and kills someone. An example of the level of quality that would be delivered is the software that ran on the space shuttle. See this article https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff for an insight into how it was developed and the practises required. I don't think all software developers should be software Engineers, but being able to lead a team to enforce quality (and not sign off on poorly thought out "MVP" crapware) would guarantee that the software that came out of that team would be reliable and well designed. It would be good for software engineering overall to be recognised as a legitimate branch of engineering. Unfortunately it seems like most of the industry does not have the sort of rigour needed for engineering tasks.
- thulecitizen 7y ago
  Thanks a lot!
- cr0sh 7y ago
  > It would be good for software engineering overall to be recognised as a legitimate branch of engineering. I think the only way this could happen would be if SWE only used waterfall or some similar kind of practice. Agile and the like might be able to be tweaked to work, but even there... The problem in software is that you can basically "start in the middle" of something and work your way outward; start coding something, get the design details later and refactor. You can't do that with a bridge or other regular engineering work. You have to plan, design, multiple sign-offs, etc - then build, and you can't build it randomly or a component here and there then fit it all together (well, you can to an extent, depending on the project and design), and if anything changes - well, in a real project it can't change much, not without a lot of money and time being lost. Several years back there was a series of commercials on TV, I think for an insurance company, which showed (using CGI effects) "impossible building strategies" - one showed a huge scaffolding structure and cranes building something like the Great Pyramid from the top downward (for instance); I think another had some kind of skyscraper being built from the middle outward or something of that nature. That's essentially SWE applied to regular engineering - or at least, that's how it feels at times. Now tack on Agile and other practices, and it gets 10x worse. Actual engineering is a strict discipline, starting with almost set-in-stone practices along with a lot of hard-won knowledge about materials and mechanics (books filled with tables and diagrams), that are then all used to inform an engineering design, which is then tested and retested in simulation, perhaps coupled with scale models that are also tested, and the plans changed and signed off by multiple other engineers, etc - long before it ever gets to building the thing. And then that thing is built in a very specific and strict manner; I won't further belabor the point. Even with all of this, sometimes things fail terribly. Today in software, we have a ton of tools and practices we are constantly trying - and despite all of them, at least from my perspective - things really haven't gotten much better than they were 20-30 years ago. I would say that widespread use of software versioning tooling and testing frameworks, etc (plus automated build and deployment) have made some of it better - but even after all that, we still seem to be making the same number of bugs and errors that we had before (and rather than a QA department usually, we've farmed this out to the end user for the most part). So while I'd love to see SWE become more like regular engineering practices (with the selfish request that I and others like me could be "grandfathered" in, as I don't have any kind of compsci or comparable degree, but I have been doing this for 25+ years) - I just don't see it happening for the above rational and reasons. I could be wrong, though (and if anyone has a counter argument, please post it - I'd love to read it)...

Stratoscope 7y ago

You may have some good points, but when you quote someone word for word, substituting your own words for some of theirs, you are twisting their words and putting words in their mouth, in essence ridiculing them. That rarely leads to a civil discussion that other people can learn from. I realize that this kind of misquoting is a traditional "hacker" style of debate. But speaking only for myself, it really rubs me the wrong way. If you disagree with someone, don't resort to cheap shots like that. Make your point in your own words and with your own logic. You will have a stronger argument and a better chance of informing and educating the rest of us.

imtringued 7y ago

This is a strawman. Why are you talking about public infrastructure in a submission about privately owned vehicles that are exclusively used on privately owned land that has no paved roads or any significant traffic?