Earlier quoted context omitted.
it's like blaming the assembly line worker for a badly designed car. Software engineers don't solve problems, they implement solutions someone else thinks will solve a problem.
Was thinking about this the other day: in big companies SWE individual contributors are the new line workers. Large enterprise ends up trying to manage them with business metrics goals without much visibility into the process issues that hamper overall quality or the production efficiency. Has anybody thought to apply the Toyota Production System in Engineering management? https://en.wikipedia.org/wiki/Toyota_Product…
Programmers who want to change how we code before catastrophe strikes
61–70 of 274 posts
Re: Programmers who want to change how we code before catastrophe strikes
#62This article is silly in a lot of ways. The real problem of software engineering is not "how do you prove this code follows algorithm X exactly?" It's "how do you know what algorithm X needs to be in sufficient detail to implement it?" It's "when you realize you were wrong about algorithm X, how do you change your existing, working code to implement the new algorithm X-prime, without interruption?" It's "what do we d…
Re: Programmers who want to change how we code before catastrophe strikes
#63Earlier quoted context omitted.
> The only difference is that these other engineers are motivated to be significantly more thorough about their jobs. Hang on. Sure, all engineering has hurdles. But how many engineering projects face regular enemy action? The last time somebody actively tried to compromise a system I was building was two weeks ago. How many engineers live like that? We hold civil engineers responsible when bridges collapse unprompte…
Most of the article, and the comment you're replying to, wasn't about hackers, though. It gave the example of people dying because the Therac machine or a Toyota car responded wrongly to non-malicious, normal user input, like a "bridge collapsing unprompted" in normal use.
But with the post I responded to? I see this idea of "it's because engineers don't care, so give them liability" a lot, and frankly it's stupid. It neglects both cost-benefit differences and any interest in the question of hacking, and then goes on to pretend that you can fix bad systemic pressures by beating up the guys at the bottom. The difficulty of writing good code is not a function of how heavily you punish bad code.
I flatly don't believe that the Therac bug would have been caught by personal liability for the bug; either the code would have been cancelled altogether to avoid liability or the bug would have gone on unabated. Realistically, criminal liability for lethal bugs mostly sounds like a way to drive talented devs away from high-stakes applications and leave those apps to be handled by people desperate enough to run the risk, or by international shops operating outside the reach of prosecution. I don't love the thought of a shop unwilling to use git because it creates personal responsibility. "Oh, we just pass code around on thumbdrives, I can't remember who wrote that critical line."
I'd shrug and let the whole thing go, but the rumblings of "regulate software" keep getting stronger from a lot of directions. I don't really want to wake up in a decade and find out that degree requirements and expensive-but-useless licensing have become mandatory, and it feels like pretending bugs come from lazy devs is another snowflake in that avalanche.
Re: Programmers who want to change how we code before catastrophe strikes
#64The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when…
Regulation like that tends to follow after a series of disasters causing massive loss of life. Software hasn't yet managed to achieve that.
Re: Programmers who want to change how we code before catastrophe strikes
#65The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when…
> The only difference is that these other engineers are motivated to be significantly more thorough about their jobs. Hang on. Sure, all engineering has hurdles. But how many engineering projects face regular enemy action? The last time somebody actively tried to compromise a system I was building was two weeks ago. How many engineers live like that? We hold civil engineers responsible when bridges collapse unprompte…
Re: Programmers who want to change how we code before catastrophe strikes
#66The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when…
> The only difference is that these other engineers are motivated to be significantly more thorough about their jobs. Hang on. Sure, all engineering has hurdles. But how many engineering projects face regular enemy action? The last time somebody actively tried to compromise a system I was building was two weeks ago. How many engineers live like that? We hold civil engineers responsible when bridges collapse unprompte…
The issue isn't exactly how software fails, but that software today doesn't properly protect confidentiality and integrity of data, ensure services and data are available without providing oracles, authenticate and authorize correctly, log properly, etc. This is a well known methodology that is consistently ignored in preference to shipping products immediately. That's the issue.
Unexpected things happen, accidentally or maliciously, but care should be taken - the proper kind of non-negligent care called due care. In general, software is not fit for the purpose it was created, appearing to work even though it really doesn't.
Re: Programmers who want to change how we code before catastrophe strikes
#67Earlier quoted context omitted.
it's like blaming the assembly line worker for a badly designed car. Software engineers don't solve problems, they implement solutions someone else thinks will solve a problem.
Was thinking about this the other day: in big companies SWE individual contributors are the new line workers. Large enterprise ends up trying to manage them with business metrics goals without much visibility into the process issues that hamper overall quality or the production efficiency. Has anybody thought to apply the Toyota Production System in Engineering management? https://en.wikipedia.org/wiki/Toyota_Product…
Re: Programmers who want to change how we code before catastrophe strikes
#68The article didn't mention it, but I think that Excel is a great example of where "the masses" have learned to do programming. It is visual and the effects of changes are immediate.
The effects of a change may be immediate, but not necessarily immediately obvious. Subtle bugs are a problem in any programmable system.
1. https://www.bloomberg.com/news/articles/2013-04-18/faq-reinh...
2. https://www.cio.com/article/2438188/enterprise-software/eigh...
Re: Programmers who want to change how we code before catastrophe strikes
#69The article didn't mention it, but I think that Excel is a great example of where "the masses" have learned to do programming. It is visual and the effects of changes are immediate.
Re: Programmers who want to change how we code before catastrophe strikes
#70Some points the author makes I agree with, others I don't. Nothing will change until incentives change.