5 ms·

I'll play Devil's Advocate here: there are sometimes critical business deadlines that absolutely require timeboxing a bug at the risk of losing a contract. I wi

I'll play Devil's Advocate here: there are sometimes critical business deadlines that absolutely require timeboxing a bug at the risk of losing a contract. I wish the world could conform to SDLC best practices, but sometimes reality is messy, and hindsight is 20/20. So that said, I think the real problem here is what you alluded: several people attempted unsuccessfully to solve it: how many man hours was this? How any calendar days? Did you report this up the chain early on, or was management blindsided by it because you kept hacking on it as shadow work, or didn't communicate how critical it was? If you did your due diligence early on, then I agree with everyone saying you should leave. If the people issuing the directive didn't receive adequate warning from your team, fix that next time.

andrewla 5y ago
> deadlines that absolutely require timeboxing a bug To be clear, timeboxing is usually used in the opposite sense, to say "if this bug is not fixed by end-of-day then we should abandon the effort because the value of fixing it is limited". It can be useful to timebox the amount of time that you spend trying to find the "right" fix before falling back to a workable solution -- like "if you can't fix the problem with the email sender by end of day we're going to send out the emails manually".
bjohnson225 5y ago
> I wish the world could conform to SDLC best practices, but sometimes reality is messy Reality is messy, but what the OP describes is the denying rather than dealing with that reality. Putting a two day limit on a bug fix is not going to make what could potentially be two weeks of round the clock work suddenly become two days worth of work.