11 ms·

> test it quickly Yes, in your scenario the lack of testing stands out as the major opportunity for improvement. If a bug is so important that it's mentioned

> test it quickly Yes, in your scenario the lack of testing stands out as the major opportunity for improvement. If a bug is so important that it's mentioned in a performance review, then it's important enough that there should be tests that would have caught it. Automated preferably, or manual if necessary. And everyone involved with the software, from you on up and sideways, should be calling for this testing. It's clearly important / worthwhile!

tombert 5y ago
There actually were unit tests for it, there was just an edge case I didn’t think to test that caused things to crash, which caused a cascading error.
- dsjoerg 5y ago
  Sure. Seems like a classic "seven whys" kind of situation... coming down hard on the person who wrote the bug is counterproductive in a way that the whole tech industry understands, except for your former bosses at Apple.
  - tombert 5y ago
    To be clear, I’m not absolving myself on this. The bug was still my fault at the end of the day, I just feel like my managers handled it poorly.
    - kqr 5y ago
      Did you purposefully introduce this bug? Then it was your fault. Otherwise, from all the evidence we have, you couldn't predict it from where you were standing at the time. You can't be at fault for that. Any other conclusion is a cultural problem that hints at a "shoot the messenger" philosophy ruling. If we want a Westrum generative culture (and we do!) we can't go around assigning fault to ourselves or others when we end up in bad situations. Focus on whether the process is good or bad, not where individuals ended up due to random variance around the mean. End rant. Sorry, this is one of the major things that upset me about how other people run their organisations.
- janstice 5y ago
  Edge cases and cascading failures are things that code reviews should be focusing on, as that’s a place where more brains is better than one, rather than the usual “does the code match the formatting and naming conventions”.

tombert 5y ago

There actually were unit tests for it, there was just an edge case I didn’t think to test that caused things to crash, which caused a cascading error.

dsjoerg 5y ago
Sure. Seems like a classic "seven whys" kind of situation... coming down hard on the person who wrote the bug is counterproductive in a way that the whole tech industry understands, except for your former bosses at Apple.
- tombert 5y ago
  To be clear, I’m not absolving myself on this. The bug was still my fault at the end of the day, I just feel like my managers handled it poorly.
  - kqr 5y ago
    Did you purposefully introduce this bug? Then it was your fault. Otherwise, from all the evidence we have, you couldn't predict it from where you were standing at the time. You can't be at fault for that. Any other conclusion is a cultural problem that hints at a "shoot the messenger" philosophy ruling. If we want a Westrum generative culture (and we do!) we can't go around assigning fault to ourselves or others when we end up in bad situations. Focus on whether the process is good or bad, not where individuals ended up due to random variance around the mean. End rant. Sorry, this is one of the major things that upset me about how other people run their organisations.
janstice 5y ago
Edge cases and cascading failures are things that code reviews should be focusing on, as that’s a place where more brains is better than one, rather than the usual “does the code match the formatting and naming conventions”.