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…
Defects are not the fault of programmers
11–20 of 43 posts
Re: Defects are not the fault of programmers
#12No, the defects are the fault of language designers.
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.
Re: Defects are not the fault of programmers
#14IMO, 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…
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
#15Once 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.
Re: Defects are not the fault of programmers
#16Re: Defects are not the fault of programmers
#17We 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.
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
#19But 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- 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.