Live data from Hacker News

Executing Software Engineers for Bugs

blog.setec.io

61–70 of 89 posts

Re: Executing Software Engineers for Bugs

#61
post #28

Earlier quoted context omitted.

You've stated that it's not more expensive. But everyone in the industry knows otherwise. Unless you can produce some evidence to the contrary, I'm going to insist it's you who is incorrect here.

That's a highly simplistic and incorrect viewpoint—and the correctness of a model is not dependent on popular vote. When looking at increasing quality (essentially, scope) in isolation of systems and the environment in which that quality is created, then the only way to increase quality is to increase cost. That much is true, but it's also incomplete. When looking at and eventually optimizing the whole system—from th…

It's amazing you have to justify this view point.

There are books precisely documenting the correlation between quality, speed of execution and lower costs. http://ptgmedia.pearsoncmg.com/images/9780132582209/samplepa...

Re: Executing Software Engineers for Bugs

#62
post #38

Until it is the CEO..CTO..and vc that is standing under the bridge...nothing will change.

How would they know whether the bridge is designed badly? What's the reasoning behind your underlying suggestion?

> How would they know whether the bridge is designed badly?

It's their responsibility. If it's not possible for them to comprehend the design and execution thoroughly enough, they'd better make sure they had someone check it whom they can trust to understand it. Like ancient builders, who didn't lay every stone themselves, but were still responsible for the outcome.

Perhaps our standards for responsibility of leaders are a little low these days.

Re: Executing Software Engineers for Bugs

#63
post #7

When people bring up a code of ethics, actuaries seem to come up a lot because they can potentially lose their license for mis-evaluating risks, but anecdotally what I've heard is that in reality if your boss asks you to sign off on something, and you refuse they'll find someone else to sign off on it and just label you as not a team player. At which point you've harmed your career and had no real impact. I bring thi…

I agree. An ethicists/moralist does not care about the content of the interests that bring people into conflict. He wants to constrain these conflicts by an additional feat of good behavior, just so that everyone adds an additional moral attitude to what they do or must do – at work or in the family – that leads to good works instead of evil deeds.

And thinking in this schema is not only a mistake, but it produces a theoretical reversal in a certain literal sense. People experience their environment and the interests that exist in it as a conflict, as an injury. And they do not hold this experience against this environment, but against themselves: their bad behavior.

Re: Executing Software Engineers for Bugs

#65
post #53

> Unlike our brothers and sisters in the other engineering disciplines, though, software engineering does not have the same history of mandatory formal education. Was there a time when other engineering disciplines were not formally schooled? Did they develop into having formal education or were they born that way? Is computer programming moving in the same direction via organizations like the ACM? Can we learn from…

If anything, with the advent of bootcamps, software engineering is moving away from formal education and into trade schooling. Personally, I think this is a step backwards for the discipline.

I resent a little bit.

I'm a boiler-maker / welder by trade (metal fabrication). My trade certificate actually says "Engineering Tradesperson". I operate a laser cutter, and have written scripts to automate some of my computer related tasks, and have a rudimentary understanding of Python. I've also worked at an ISP in NetOps doing physical security and infrastructure.

I live in Australia so I can only speak for the system we have here: trade school is formal education, the on-campus component of trade education is delivered throughout the nation by TAFE[1] campuses. We are formally educated to build things that don't kill people, and can certainly be held responsible if our actions or omission of action leads to injury. We are expected to escalate anything we see on workshop drawings that could be problematic. Each of the tradesmen in our workshops are required to perform a weld test every six months, which is examined using ultrasound techniques, to ensure our work meets or exceeds AS1554[2]

While us tradespeople aren't the ones engineering the bridges, we are the ones building them.

Comparatively, the software development discipline is still in it's infancy, whereas the construction trades have been around for millennia. Structural Engineers and tradespeople build physical structures to withstand Category 5 cyclones, but my bank (in the top 10 globally by market cap) can hardly have a month go by where some software system doesn't fail.

The advent of bootcamps is probably a side effect of 'coding' becoming relatively easy compared to it's more esoteric history, with the advent of high-level languages like Python and Ruby. Or maybe that stuff about the average IQ increasing over time is correct, and more people have the capacity to understand writing code. Probably both.

Another comment here spoke about TDD - Test Driven Development, that's probably closer to the physical engineering disciplines with destructive testing of random batches of building materials.

1. https://en.wikipedia.org/wiki/Technical_and_further_educatio...

2. https://infostore.saiglobal.com/store/PreviewDoc.aspx?saleIt...

Re: Executing Software Engineers for Bugs

#66

An old observation, but still relevant: We really have no liability in our profession, compared to other licensed professions. Why does software quality suck? Because our customers almost never sue us if the work we do does not meet expectation.

I think this is the problem, solving people caring about software would also make them more likely to prefer more open (e.g. open source) designs.

Re: Executing Software Engineers for Bugs

#67

"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.

You don't need a title to take responsibility.

Re: Executing Software Engineers for Bugs

#68

Earlier quoted context omitted.

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.

This is garbage and you know it. You're choosing to be deliberately blind to an accurate assessment of the consequences. If we took the article at its word, you would be put to death.

Proposals for codes of ethics are about this exact issue - you don't get to build something that provides capability, then put up your hands and say you "didn't know what it was for" when it's used for something bad.

Re: Executing Software Engineers for Bugs

#69

Earlier quoted context omitted.

That's a highly simplistic and incorrect viewpoint—and the correctness of a model is not dependent on popular vote. When looking at increasing quality (essentially, scope) in isolation of systems and the environment in which that quality is created, then the only way to increase quality is to increase cost. That much is true, but it's also incomplete. When looking at and eventually optimizing the whole system—from th…

For all you detractors, here's my story, maybe it will help you believe that quality is possible in our industry. I have been doing professional software development since 1997, and from then until two years ago, I have been a developer on waterfall and scrummerfall projects. There have been deathmarches aplenty and lots of failures small and large with some heroic successes here and there. Overall, I'd say the perfo…

Thank you. It is incredible how much resistance there is to the idea that quality is a positive feedback loop of value -- not simply a cost.

Re: Executing Software Engineers for Bugs

#70
post #40

Earlier quoted context omitted.

That's a highly simplistic and incorrect viewpoint—and the correctness of a model is not dependent on popular vote. When looking at increasing quality (essentially, scope) in isolation of systems and the environment in which that quality is created, then the only way to increase quality is to increase cost. That much is true, but it's also incomplete. When looking at and eventually optimizing the whole system—from th…

Either you're wrong or literally every software company on the planet is wrong. I'm betting it's you. Please do prove us all wrong by starting up a software company that produces bug free software faster and cheaper than every other software company on the planet. There's a big pot of gold at the end of that journey. Go and claim it. If everyone else is as incompetent as you claim, it's going to be a walk in the park…

Not only software companies, but most companies in the US are indeed wrong about the prevailing methods and styles of management and leadership. Is this really that surprising to you? Do companies you work with appear chaotic yet surprisingly successful? Do the same things keep going wrong? Do they get in cycles of cultural upheaval? And do we accept these things as "normal business" and go on with out lives, powerless to control them?

And I'm not saying it's easy. Not at all. It might be the hardest problem in all of business—combining the true systems of work into a cohesive philosophy: systems, statistics, people, and knowledge. I'm just saying (and I'm just repeating the words of some great thinkers in the quality space, mind you) that if we change the way we think about quality and companies in general, we'll get a lot of gigantic unrealized gains in productivity.

This happens naturally in many companies in small pockets, but human nature and psychology tends to break it down eventually.

If I'm wrong, then a great many other people are also wrong, primarily W. Edwards Deming, who, as I noted, single-handedly turned around the entire economy of Japan using these exact methods and ideas.

Here's a great place to start: http://www.amazon.com/Leaders-Handbook-Making-Things-Getting...

Post reply on HN