Live data from Hacker News

Defects are not the fault of programmers

buttondown.email

11–20 of 43 posts

Re: Defects are not the fault of programmers

#11

IMO, if the defect is because some functionality wasn't specified and there's an edge case, that's not the programmer's fault. OTOH, if the required functionality is documented and it doesn't work, that is the programmer's fault. > A lot of the nastiest bugs come from components that are all correct in isolation but interact in a dangerous way. This is called a Feature Interaction Bug. IMO, the original programmers o…

If functionality wasn't specified, then it's not a defect, it's working as expected.

Re: Defects are not the fault of programmers

#13

> “Defects are the fault of programmers” may sound good, but it does nothing to help us fix defects. The utility you gain by believing or disbelieving a statement has no bearing on its truthfulness.

If a statement about the nature of defects doesn't aid in fixing defects, it almost certainly doesn't fully capture the nature of defects.

Re: Defects are not the fault of programmers

#14

IMO, if the defect is because some functionality wasn't specified and there's an edge case, that's not the programmer's fault. OTOH, if the required functionality is documented and it doesn't work, that is the programmer's fault. > A lot of the nastiest bugs come from components that are all correct in isolation but interact in a dangerous way. This is called a Feature Interaction Bug. IMO, the original programmers o…

I like to use this phrase for this sort of thing: "It's working as designed but the design was flawed."

That's pretty successful at getting the business/product people off the blame-assigning game and thinking productively towards resolving the interaction and defining a solution.

Re: Defects are not the fault of programmers

#15

Once you've introduced the concept of "blame" for a situation it's hard to get out of it. It's unhealthy, IMO. Instead, I prefer to focus forward on what to do next and how to avoid this particular issue again... and simply move on.

Agreed. It's also a distraction from doing work. (Sometimes a shockingly expensive distraction.)

Re: Defects are not the fault of programmers

#16
It's a mistake to think when something goes wrong there must be a single person (or rule) to blame. If a program does not behave according to spec, then presumably the programmer made a mistake, unless satisfying the spec is impossible. But if the defect made it past qa, then the qa must be imperfect also. And if your programmers and qa team are all a bunch of fuckups, maybe your hiring process is flawed also. And so on.

Re: Defects are not the fault of programmers

#17
Defects are the fault of a lot of factors. The reason our skyscrapers rarely fall down is that there is societal pressure against them falling down. So we create laws that enforce that buildings conform to a set of standards. Some places have more prescriptive standards than others, and the result is that there is less room for creativity by the architects and engineers, but it makes the average case easy to reason about. Some places have performance based standards which come with their own downsides, but the end result is that if a building comes down in a first world country, it's a pretty big deal.

We could do this with software, but the world would look very, very different. We haven't had too many major destructive acts outside of privacy leaks, so there isn't pressure and resulting political will to regulate the industry, so economic pressures dominate what software looks like. Things like CSP headers are a distant, distant afterthought. People can't even keep their OSes, libraries, and runtimes current.

Plus software is harder to reason about than a building. Things can squeeze in or out through the smallest crack and nobody on the planet really knows whats going on in a modern cellphone or self-driving car top to bottom.

That said, I take responsibility for the security holes and bugs I create. There is no other way of being a professional software developer, even if it is hard.

Re: Defects are not the fault of programmers

#18

> “Defects are the fault of programmers” may sound good, but it does nothing to help us fix defects. The utility you gain by believing or disbelieving a statement has no bearing on its truthfulness.

I see the flip side, the "cost" on being made the "escape goat" because the lens is only the developer is a fault. Verse the team owning the complete system. Which is still a toxic mindset to be trying to minimize perceived punishment. Or if the environment is not collectively responsible aka blaming then that is the problem.

But the high level point of framing I think is very on point. You can only justify altering that which you measure, and if you only blame/measure/inspect the developer, you are missing stuff.

Re: Defects are not the fault of programmers

#19
It seems like it would be a lot easier to say "Bob Martin is not my cup of tea." He's not mine either. I've read a bunch of his stuff. Some good ideas, some I definitely don't agree with. I don't love his writing style.

But you said "explain why we don't like Robert Martin", which to some extent says its a problem with the man himself, not his point of view on software defects. Starting your post that way undermines your conclusion and makes it seem as if you're post-hoc rationalizing your dislike of the mine rather than talking about software methods.

Re: Defects are not the fault of programmers

#20
I wish more people would understand (and the article alludes to it) that testing is only one of the three general methods to achieve software quality (lack of defects), the other two being:

- Abstractions - preventing bugs by having a proper language in which to express the ideas

- Assertions - making sure that certain assumptions are satisfied during the actual execution of the code, AKA defensive programming

And in particular, unit testing is IMHO a rather weak method of testing, compared to property-based or integration testing. There is this famous quote "bad programmers worry about the code, good programmers worry about the data". Similarly, I believe we should spend more time testing the assumptions that we have about data (can this value be 0?) rather than testing the logic of the code under the same and possibly wrong (or unstated) assumptions.

Post reply on HN