Live data from Hacker News

Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

news.ycombinator.com

11–20 of 67 posts

Re: Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

#11
post #3

First: discuss with your development team the issue, make sure you get buy-in on replying to management with one voice. A.K.A.: avoiding you saying "We can't do X" and someone else goes: "Of course we can!". Second: talk to your manager. Don't send an e-mail. That would just turn in a long, and possibly bitter, battle of 're:re:re:re:' or be interpreted as a C.Y.A. fig leaf. Make sure you start by understanding where…

I think this is probably about as close as we will come to a process that would work. I'd say that right now the company I'm working for doesn't have the structure in place - no team leads, for instance - to dissipate the heat when it's on, and no procedure to follow when things go wrong. These are definitely things to think about as we grow. Thanks for the constructive reply!

Glad to help, I have been in your spot; until you get the structure in place just make sure that the team is in agreement on the response.

I always believe in good faith and positive intent - call me naive - so I assume the managers have their own pressure to respond to and business needs to satisfy.

The 'understanding' first step is needed to see if there is an interim solution that takes the fire away from the business, the manager and the dev team. IE: The feature with the bug is not as urgent as other features in the same drop; squirrel away the bug behind a feature flag and deliver the rest. Now you can go ahead and fix the bug with a proper pace.

Re: Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

#12
post #3

First: discuss with your development team the issue, make sure you get buy-in on replying to management with one voice. A.K.A.: avoiding you saying "We can't do X" and someone else goes: "Of course we can!". Second: talk to your manager. Don't send an e-mail. That would just turn in a long, and possibly bitter, battle of 're:re:re:re:' or be interpreted as a C.Y.A. fig leaf. Make sure you start by understanding where…

Yep, take a look at how GGG handled latest POE patch. Seems there was an issue with db paging but it's hard to find and took about 13 hours or so to fix.

Sometimes bugs are really hard to track-down, it's important to learn and not make the same mistakes going forward though.

Re: Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

#13
Just communicate that setting a _priority_ for a bug is fine, but a timescale isn't, as you don't know what you don't know. Then let them know what resources you need to figure it out as quickly as possible (maybe it's just space and time, maybe it's people, maybe it's expertise).

Re: Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

#14
If you go to your mechanic and tell them "car won't start", does your mechanic have idea how long it's going to take to fix or how much money it will cost? Realistically, you will be charged a fee to figure out what is wrong, and another to fix the problem.

When you have a bug, you are still figuring out what is wrong.

Re: Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

#16
The problem will solve itself by the time the deadline comes and the bug is not fixed.

Meanwhile, don't promise anything, don't commit to anything but don't burn any bridges. Be professional, explain what do you think it is, what might be wrong and why is it hard.

"This bug will require a longer investigation and we cannot commit to any timeframe for its resolution" (unless you have a fallback/workaround ready or it is something you don't expect to be complicated)

Re: Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

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

Re: Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

#18
I think being honest will not affect your career in a negative way. In this particular instance, it could potentially harm this job now, however if telling the truth gets you fired, that is not a place where you want to work.

Hearing your baby is ugly is painful but a necessary part of business, if we can't be ruthlessly honest with each other, then no one wins.

Re: Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

#19
Thoughts in my head:

* They should be aware from the onset that this requires investigation first of all. You would provide them with an update to see if you can actually timebox it midway into the process (be that the EOD or on another day)

* After having recognized that this problem was just a configuration issue, one should write down why that bug was so difficult to find and what is the work to be done to make that issue more visible?

* Speak to your personal manager and talk through the problem. Maybe they can share the insights with the management team.

Re: Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

#20
post #3

First: discuss with your development team the issue, make sure you get buy-in on replying to management with one voice. A.K.A.: avoiding you saying "We can't do X" and someone else goes: "Of course we can!". Second: talk to your manager. Don't send an e-mail. That would just turn in a long, and possibly bitter, battle of 're:re:re:re:' or be interpreted as a C.Y.A. fig leaf. Make sure you start by understanding where…

Step 2 is key. You need to understand why the pressure exists. Is the CEO demoing the software and does not want a big error screen to pop up? Is your biggest customer complaining? Does you CTO need his Etch-a-Sketch reset?

You also need to understand what constitutes success. Can you disable feature X?, Can you catch the error and log it but not display or stop execution? Can you do a quick hack workaround while you take longer to fix it.

Post reply on HN