Defects are not the fault of programmers
buttondown.email
Defects are not the fault of programmers
1–10 of 43 posts
Re: Defects are not the fault of programmers
#2Well 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 were supposed to and didn't realize it, and then they will no longer be happy.
Re: Defects are not the fault of programmers
#3IMO, 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 of those components are not at fault, but if someone uses those components together and doesn't verify that they're working as desired, that "someone" is at fault.
Sure, stricter discipline won't always help, but sometimes it will. Sometimes, the programmer really is just being lazy.
And I say this as a programmer.
Re: Defects are not the fault of programmers
#4> “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
#5Defects are the fault of programmers but programmers are pressured to deliver quickly and judged on their ability to deliver quicker than another (in some cases, not all). Given this, the blame can be pushed onto the person setting a timeline if and only if they don't give the programmer enough time to evaluate a solution and implement based off of that evaluation.
If the programmer is given an opportunity to evaluate the scope of the work and allowed to communicate the time they think it will take, then any fault in the resulting work is the fault of the programmer.
What I've seen are programmers unwilling to spend the time necessary to fully understand the work they are doing and managers/sales people/whohaveyou who push for aggressive timelines.
Re: Defects are not the fault of programmers
#6[deleted]
Re: Defects are not the fault of programmers
#7Once 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
#8No, the defects are the fault of language designers.
Re: Defects are not the fault of programmers
#9> “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 think the discussion here is about how we should use the term "fault".
I don't think it's the case that we all have shared definition of exactly what "fault" means, leaving us only to deduce from that where the fault for defects lies.
So I don't think the maxim you stated is helpful here.
Re: Defects are not the fault of programmers
#10Well 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.