4 ms·

I'm fairly certain that you aren't accounting for uncertainty properly, especially with long-tail events. Let's say you have a ticket to enable a config flag. T

I'm fairly certain that you aren't accounting for uncertainty properly, especially with long-tail events. Let's say you have a ticket to enable a config flag. That's low risk and relatively small. There's still a risk that there's the flag hits a silicon bug. Does your estimate reflect that risk and is it useful if 95% of tasks don't hit those issues? Consider also that estimates delivered by contractors or even other teammates will not reflect these risks and thus you look correspondingly pessimistic or even lazy. For context, my team is in exactly this situation with several silicon bugs we found last month.

dclusin 4y ago
Assuming you’re pretty close to the hardware? As a standard backend web service dev os/library/device bugs are incredibly unlikely and usually defective application software is to blame. Not saying it doesn’t happen, but I can’t recall in recent memory this sort of thing happening as high up in the stack I work.
- AlotOfReading 4y ago
  That's just the sort of stuff I see, but long tail issues that take weeks or months to diagnose can happen anywhere in the stack. Sometimes it's a hardware issue, sometimes it's a compiler bug, sometimes a VM bug, a missing browser feature, etc. Any of that can crop up even with "trivial" changes. I'd argue that it's not useful to include that in your estimates, but they're nevertheless possible and need to be incorporated in scheduling.
antipotoad 4y ago
May I ask how you identified them as silicon bugs? And by silicon bugs do you mean random bit flips, or something else?
- AlotOfReading 4y ago
  I probably should have said hardware bugs, as only one is in an IC (specifically an IP block). It manifests as small (but out of spec) timing errors across a network. The rest are things like improper layout, faulty components, wrong value passives, etc.

dclusin 4y ago

Assuming you’re pretty close to the hardware? As a standard backend web service dev os/library/device bugs are incredibly unlikely and usually defective application software is to blame. Not saying it doesn’t happen, but I can’t recall in recent memory this sort of thing happening as high up in the stack I work.

AlotOfReading 4y ago
That's just the sort of stuff I see, but long tail issues that take weeks or months to diagnose can happen anywhere in the stack. Sometimes it's a hardware issue, sometimes it's a compiler bug, sometimes a VM bug, a missing browser feature, etc. Any of that can crop up even with "trivial" changes. I'd argue that it's not useful to include that in your estimates, but they're nevertheless possible and need to be incorporated in scheduling.

antipotoad 4y ago

May I ask how you identified them as silicon bugs? And by silicon bugs do you mean random bit flips, or something else?

AlotOfReading 4y ago
I probably should have said hardware bugs, as only one is in an IC (specifically an IP block). It manifests as small (but out of spec) timing errors across a network. The rest are things like improper layout, faulty components, wrong value passives, etc.