Who's fault is it when a Jenga tower is toppled?
Was it the last person to pull a piece out?
Maybe the person before, who barely managed to keep it upright?
Or is the tower doomed to fall by design?
Defects are not the fault of programmers
21–30 of 43 posts
Re: Defects are not the fault of programmers
#22> “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.
That might or might not be accurate, but I still care about utility. There are a lot of truths that don't have any utility for me. I celebrate not knowing most of those truths.
I mean do you want to be on this call? ... A: "One point seven million dung beetles can fit in my suitcase." B: "Let's get back to work." A: "Utility has no bearing on truthfulness."
Re: Defects are not the fault of programmers
#23IMO, 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…
> some functionality wasn't specified and there's an edge case
Edge cases are extremely rare. If they weren't they'd not be an edge case. But, we should still try and build robust systems and not allow the system to be in an unknown state. It isn't, "I have to think of all the possible cases." No, it's "These are the possible cases, nothing else is allowed."
If the cases were not specified, as you mention, then that is not completely a dev issue.
Re: Defects are not the fault of programmers
#24> Defects are not the fault of programmers
It's not that it's wrong. It's just really, really unproductive.
Rust language and community capitalized greatly on taking the opposite approach after years of stupid attitude like this present in systems languages community.
BTW. Uncle Bob has his opinions, good for him. They are not much more worth than anyone's else.
Re: Defects are not the fault of programmers
#25> “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.
That might or might not be accurate, but I still care about utility. There are a lot of truths that don't have any utility for me. I celebrate not knowing most of those truths. I mean do you want to be on this call? ... A: "One point seven million dung beetles can fit in my suitcase." B: "Let's get back to work." A: "Utility has no bearing on truthfulness."
I do not want to be on that call. However, if following this exchange, person B goes on to write a blog post titled "One point seven million dung beetles CAN NOT fit in my suitcase" and justifies this claim by saying that knowing how many dung beetles fit in a suitcase is not a useful thing to know, then despite how right they are about the utility, their conclusion is wrong.
Re: Defects are not the fault of programmers
#26The responsibility for bugs and software not behaving as specified falls on the dev. team. This sort of defects is their collective 'fault' or responsibility because even if a single dev. tries to cut corners or is not very thorough there should be internal processes to catch it.
Now, "behaving as specified", well, having clarity on that can often be a big problem. The dev. team does have some responsibility there as well because they should push for clarity instead of trying to interpret on their own. I've seen it many times: spec defines something in vague terms, dev implements it the way (s)he decides to interpret/imagine it without even asking for confirmation.
Re: Defects are not the fault of programmers
#27React was invented because anytime developers at Facebook touched code regarding unread messages/notifications, they would introduce a defect. You'd find the error and then fix it, but it was fundamentally a minefield. So, they had to invent a new way of building frontends, and then all those defects went away.
Now, I do tend to believe, that there still is a lot of low-hanging fruit with regards to programmer discipline. Many juniors (and some seniors) just straight up don't pay attention to things, don't check things, don't think things through to their obvious conclusion. You can then try to add policy to try to force them to do these things, like, e.g. you must have 100% coverage on your code, maybe that'll force them to try running their code at least once before merging into master. But then of course that must be a blanket policy for everyone, and you know how the story goes.
Re: Defects are not the fault of programmers
#28Well the worst defect I've seen in a while is sitting unnoticed in a program I wrote and was specifically required by the owner after months of argument against it, references to scholarly works showing why it was stupid, explanations for how search engines work etc. etc. Right now customers are happy, but I expect some time in the next year someone is going to get a big fine because they didn't find the data they we…
I hope you have that in writing.
As a matter of fact I do. Although the way things are structured I doubt anyone would come to blame me.
Re: Defects are not the fault of programmers
#29IMO, 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…
> some functionality wasn't specified and there's an edge case Edge cases are extremely rare. If they weren't they'd not be an edge case. But, we should still try and build robust systems and not allow the system to be in an unknown state. It isn't, "I have to think of all the possible cases." No, it's "These are the possible cases, nothing else is allowed." If the cases were not specified, as you mention, then that…
Edge cases are common. Corner cases are rare.
Re: Defects are not the fault of programmers
#30Well the worst defect I've seen in a while is sitting unnoticed in a program I wrote and was specifically required by the owner after months of argument against it, references to scholarly works showing why it was stupid, explanations for how search engines work etc. etc. Right now customers are happy, but I expect some time in the next year someone is going to get a big fine because they didn't find the data they we…
I hope you have that in writing.
anyway maybe I'm wrong, maybe everything will be great and my worries are baseless. maybe I'm overly cautious about engineering things.