Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defects are not the fault of programmers

buttondown.email

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Defects are not the fault of programmers

#31

Post by TheCoelacanth »

mytailorisrich wrote: post #26

The 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…

I agree, but only provided that the dev team has the authority to set their own processes for ensuring quality, to refuse inadequate specifications, to refuse timelines that don't leave enough time for ensuring zero defects. Take away any of those things, and they are no longer responsible.

Re: Defects are not the fault of programmers

#32

Post by wool_gather »

inanutshellus wrote: post #7

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.

Well, you can't know how to avoid it until you know how you got into it. Which is one form of "blame" -- though I would agree it's more productive not to direct it at a person, and instead blame features of the situation.

Re: Defects are not the fault of programmers

#33

Post by iimblack »

jgwil2 wrote: post #11
wccrawford wrote: post #3

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.

Unfortunately many companies don’t differentiate.

Re: Defects are not the fault of programmers

#34

Post by eindiran »

gowld wrote: post #29
chooseaname wrote: post #23

Earlier quoted context omitted.

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

I'm not familiar with this distinction: what is the difference you're pointing to here?

Re: Defects are not the fault of programmers

#35

Post by greenyoda »

jgwil2 wrote: post #11
wccrawford wrote: post #3

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.

Some functionality should be common sense to a competent developer, and not have to be specified. As a developer, I'd expect working code to have the following behavior, whether or not it was explicitly written into the spec:

- If the credit card transaction fails, do not ship the product to the customer, and notify the customer of the failure.

- Don't let the customer order more items than are available in our inventory, or zero items, or a negative or non-integer number of items.

- A web-based system should correctly handle multiple concurrent transactions.

- If something goes wrong, show the user a meaningful error message in their selected language, not a Python stack trace.

If my excuse for my code not doing this was "it wasn't in the spec", I'd expect people to ridicule me.

Re: Defects are not the fault of programmers

#36

Post by bobbiechen »

About the hosting site (Buttondown) - does anyone know what "Unlock full access" does?

I liked the post, so I filled out the newsletter signup form with my email. It immediately switched to show a credit card form to "Unlock full access" for $25/month. I was annoyed by this bait-and-switch, only to find that apparently it's all already accessible [1] and I received a confirmation email with a link to subscribe. So now I'm just confused.

[1] https://buttondown.email/hillelwayne/archive

Re: Defects are not the fault of programmers

#37

Post by hwayne »

bobbiechen wrote: post #36

About the hosting site (Buttondown) - does anyone know what "Unlock full access" does? I liked the post, so I filled out the newsletter signup form with my email. It immediately switched to show a credit card form to "Unlock full access" for $25/month. I was annoyed by this bait-and-switch, only to find that apparently it's all already accessible [1] and I received a confirmation email with a link to subscribe. So no…

Buttondown lets you send emails to just paying subscribers of the newsletter, kinda like substack. I was playing around with the config and didn't realize it would ask people to pay! I am very dumb.

Anyway, I disabled it. There is no paying-subscriber-only content and I don't plan to offer any in the near future. Sorry about that!

There's some archive posts[1] that are only for newsletter subscribers. Those are usually first drafts of blog posts I'm writing and don't want to be shareable yet. But that's just a newsletter subscription and totally free.

[1] https://buttondown.email/hillelwayne/archive

Re: Defects are not the fault of programmers

#38

Post by virgilp »

jgwil2 wrote: post #11
wccrawford wrote: post #3

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.

"working as expected" doesn't preclude defects. As expected by whom? There's always a range of expectations to consider... take the iPhone4 antenna, was it a bug or just people "holding it wrong"/ intentionally squeezing the phone to demonstrate signal loss?

Or, take programming languages - is the null pointer "working as expected", or is it a "billion dollar mistake"?

Re: Defects are not the fault of programmers

#39

Post by mytailorisrich »

TheCoelacanth wrote: post #31
mytailorisrich wrote: post #26

The 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…

I agree, but only provided that the dev team has the authority to set their own processes for ensuring quality, to refuse inadequate specifications, to refuse timelines that don't leave enough time for ensuring zero defects. Take away any of those things, and they are no longer responsible.

The dev team has authority to set internal processes, and in any case nothing prevents it, like nothing prevents a dev from trying to clarify a spec.

Issues can go beyond the dev team of course, but they cannot escape their responsibility.

Re: Defects are not the fault of programmers

#40

Post by tom-thistime »

tengbretson wrote: post #25
tom-thistime wrote: post #22

Earlier quoted context omitted.

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.

Sure. They should claim "it doesn't matter," not "it's false." By the end of the article I felt the author said something like "substitute more design space and dev activity for blame analysis."
Post reply on HN