Live data from Hacker News

Executing Software Engineers for Bugs

blog.setec.io

11–20 of 89 posts

Re: Executing Software Engineers for Bugs

#11
post #5

We can write software like this. The reason why we don't has been explained many times: It's too expensive, by many orders of magnitude.

If it's financially impossible to make a product that doesn't harm people, you don't say "gosh, sorry, but your safety is incompatible with our fiscal goals." You cancel the fucking product.

And beyond that, I don't believe for a moment that--to use the example from the article--it would have increased Grindr's costs by 1000x if they had taken a little while to brainstorm possible negative consequences of an app that lets gay people be anonymously tracked and located worldwide. "Too expensive" is code for "we've decided that the safety of our users is less important than maximizing our profit margin."

Re: Executing Software Engineers for Bugs

#12

Those of you with a membership in ACM or IEEE, I'm interested in hearing your thoughts on why you do. Those of you who don't, would you consider pledging yourself to a code of ethics if they met your requirements? What would those requirements be?

Shipping with bugs is a fact of life. Living with tech debt is an economic necessity because if you don't some other company will and they'll eat your lunch. The comparison with physical infrastructure doesn't really hold up.

I've been a member of ACM primarily because I wanted easier access to ACM library papers, but not any more. I'm uninterested in turning software engineering into a gated discipline with a professional organisation acting as a monopoly keyholder.

Software as a discipline affects too many areas of life for anything much more than a vague platitude as a code. Components may be used for good or evil in ways we can't control. Even something as potentially evil as Metasploit is also almost exactly the same thing you want to use to test for vulnerabilities (personally I would not write a plugin for it).

Re: Executing Software Engineers for Bugs

#13
post #3

Those of you with a membership in ACM or IEEE, I'm interested in hearing your thoughts on why you do. Those of you who don't, would you consider pledging yourself to a code of ethics if they met your requirements? What would those requirements be?

If it meant having a job or not, sure I guess.

And this is the problem in a nutshell: "I'm okay with trying not to hurt people, as long as it pays better than hurting people does."

I wonder if the real difference between software engineering and other engineering disciplines is that they have a culture of responsibility--of saying "hey, public safety is more important than money"--and we emphatically don't.

Re: Executing Software Engineers for Bugs

#15
post #5

We can write software like this. The reason why we don't has been explained many times: It's too expensive, by many orders of magnitude.

I don't mean to say that all code has to be bug free; certainly, I hope the life-safety critical code is. But I think we, as hackers and software engineers, need to consider the ramifications that bugs can have, and then making the decision based on that balance of risk. Take an anonymous currency system, for example. Handwave away whether or not that it's actually possible to build one -- let's say you have a way to…

"Take an anonymous currency system, for example....Do you build that, or not?"

Obviously you do.

I don't understand why that would be a question.

Re: Executing Software Engineers for Bugs

#16

Those of you with a membership in ACM or IEEE, I'm interested in hearing your thoughts on why you do. Those of you who don't, would you consider pledging yourself to a code of ethics if they met your requirements? What would those requirements be?

If it were possible to commit programmers to a code of ethics, it would be possible to do what most professions do an organize to protect the careers and incomes of professionals. On top of the code of ethics would soon be refusing to work on any team with H1-Bs, just as doctors, lawyers, and accountants don't work with any peers who haven't passed the same qualification hurdles as they have.

I don't like the idea of extensive central regulation, but it might well be better for programmers' lives.

Re: Executing Software Engineers for Bugs

#17

Earlier quoted context omitted.

I don't mean to say that all code has to be bug free; certainly, I hope the life-safety critical code is. But I think we, as hackers and software engineers, need to consider the ramifications that bugs can have, and then making the decision based on that balance of risk. Take an anonymous currency system, for example. Handwave away whether or not that it's actually possible to build one -- let's say you have a way to…

"Take an anonymous currency system, for example....Do you build that, or not?" Obviously you do. I don't understand why that would be a question.

Even knowing it's likely to be used for buying and selling drugs, child porn, and assassinations?

I personally believe that, even given those potential ramifications, the benefits outweigh the costs -- but my personal balance of those is not everyone's.

Re: Executing Software Engineers for Bugs

#18

Earlier quoted context omitted.

"Take an anonymous currency system, for example....Do you build that, or not?" Obviously you do. I don't understand why that would be a question.

Even knowing it's likely to be used for buying and selling drugs, child porn, and assassinations? I personally believe that, even given those potential ramifications, the benefits outweigh the costs -- but my personal balance of those is not everyone's.

Yes, because it will also be used by marginalized groups to buy groceries, by sex workers who would otherwise be stuck paying huge commissions to pimps, to help hide who is buying anti-goverment printings. Every tool can be used for evil - Your drill is just as capable of drilling through someone's skull as wood.

Re: Executing Software Engineers for Bugs

#19
post #5

We can write software like this. The reason why we don't has been explained many times: It's too expensive, by many orders of magnitude.

This is simply false. True systemic quality will lower costs, speed production, and increase value all at once.

The reason is that, beyond a certain organizational complexity, we fail at creating the systems necessary to create the positive feedback loops necessary for quality, low cost, and fast execution to flourish naturally. Instead, we live in dysfunctional organizations where the tradeoffs prevail, and we choose speed and cost over quality in nearly all cases. Most of the time, we don't understand how to even begin to think about quality at an organizational level.

It's fully possible. Quality pioneer W. Edwards Deming explained the full system for creating an organization that is capable of quality in the first place. It mainly involves systems thinking, knowledge of variation, understanding psychology deeply, and creating systems of effective learning—and management and leadership versed in those new leadership competencies.

Instead our instincts are to blame, to punish, to hold accountable, effectively to leave each engineer as an island in charge of his or her own level of quality—when an organization and its production is so far removed from individual control it's not even funny.

We absolutely can write software like this—and we can do it quicker, and for lower cost. We need to work on the systems that produce and influence that quality/speed/cost relationship—not each individual part in isolation. There is a positive cycle to be achieved.

https://en.wikipedia.org/wiki/W._Edwards_Deming

Re: Executing Software Engineers for Bugs

#20

"Executing Software Engineers for Bugs" Never have I been prouder to be a plain old programmer. Those software engineers, architects, systems analysts, and data scientists can keep the capital punishment for themselves.

I hope you don't have a manager, then...
Post reply on HN