4 ms·

Minor nit regarding this thing that will destroy quality: “We'll fix it if customers complain." You can’t fix everything, and perfect is the enemy of good. Wh

Minor nit regarding this thing that will destroy quality: “We'll fix it if customers complain." You can’t fix everything, and perfect is the enemy of good. While punting testing to users is a no-no, recognizing that edge case issues can be deprioritized is crucial to getting things out the door. This means shipping stuff with known defects that you can respond to if necessary.

marcosdumay 3y ago
> You can’t fix everything Oh, you certainly can't. But you can choose how many things needing fixing you will make. Doing some shit without thinking and waiting for people to complain about symptoms of deep issues is a very effective way to create lots and lots of need for fixing things.
- mdaniel 3y ago
  And my experience has been that a quality culture like that can "resource starve" annoyances for literally years due to while True: ship_feature() if bugs: to_fix = highest_priority(bugs) fix = make_patch(to_fix) fix = introduce_new_bug(fix) # defer bugs[1:] until they meet the complaint criteria and that's how meetings end up with "but, how hard can that possibly be to fix?" statements
  - NomDePlum 3y ago
    If you accept some bugs as "features" that you will accept, not fix, you can have a bug free policy. Doing this means you make decisions early and don't carry a ton of historical baggage that gets endlessly discussed.
  - hinkley 3y ago
    I knew a guy who said on a previous project they had a system that raised the priority of old bugs on some interval. I guess the idea was to either get them fixed or agree that they never would. There are morale and duplicate bug issues with keeping a backlog that grows faster than you can close them, so I guess that makes a bit of sense. And better than GitHub auto-shooting-the-messenger by clocking bugs after a month or two of inactivity.
golergka 3y ago
> You can’t fix everything But you can fix a lot. Some of the products I've worked at had Sentry alerts all the time that nobody paid attention to, whereas others (of very similar complexity) had them a few times a week, and every time somebody would immediately get on top of it and release a hotfix, usually in a span of the same day.
adityaathalye 3y ago
OP here. I agree and I think I imply habitual punting. No product or service can completely delight every customer. I would even say customers are forgiving of minor annoyances as long as they know the Big Important things are taken care of. Yet there is some point where the minor annoyances become too many. Finding ourselves at that point could be a "too little too late" situation, with a steep cost to recover lost trust. (edit: note I am OP)

marcosdumay 3y ago

> You can’t fix everything Oh, you certainly can't. But you can choose how many things needing fixing you will make. Doing some shit without thinking and waiting for people to complain about symptoms of deep issues is a very effective way to create lots and lots of need for fixing things.

mdaniel 3y ago
And my experience has been that a quality culture like that can "resource starve" annoyances for literally years due to while True: ship_feature() if bugs: to_fix = highest_priority(bugs) fix = make_patch(to_fix) fix = introduce_new_bug(fix) # defer bugs[1:] until they meet the complaint criteria and that's how meetings end up with "but, how hard can that possibly be to fix?" statements
- NomDePlum 3y ago
  If you accept some bugs as "features" that you will accept, not fix, you can have a bug free policy. Doing this means you make decisions early and don't carry a ton of historical baggage that gets endlessly discussed.
- hinkley 3y ago
  I knew a guy who said on a previous project they had a system that raised the priority of old bugs on some interval. I guess the idea was to either get them fixed or agree that they never would. There are morale and duplicate bug issues with keeping a backlog that grows faster than you can close them, so I guess that makes a bit of sense. And better than GitHub auto-shooting-the-messenger by clocking bugs after a month or two of inactivity.

golergka 3y ago

> You can’t fix everything But you can fix a lot. Some of the products I've worked at had Sentry alerts all the time that nobody paid attention to, whereas others (of very similar complexity) had them a few times a week, and every time somebody would immediately get on top of it and release a hotfix, usually in a span of the same day.

adityaathalye 3y ago

OP here. I agree and I think I imply habitual punting. No product or service can completely delight every customer. I would even say customers are forgiving of minor annoyances as long as they know the Big Important things are taken care of. Yet there is some point where the minor annoyances become too many. Finding ourselves at that point could be a "too little too late" situation, with a steep cost to recover lost trust. (edit: note I am OP)