[valenterry]

> Spending 2-3 weeks on a bug is never good, if you're not communicating progress

Assuming that it is important to fix the bug and that the developer is competent and trusted - why not? What would communicating progress improve here?

Mind that you cannot communicate when it is done (otherwise it would not be a hard bug) you can only communicate what you have done so far and what you try next. But what kind of business value does that create?

[TameAntelope]

The value is that the developer doesn’t reasonably have the context necessary to make the call whether or not, over time, the issue is worth continuing to invest time to resolve.

Not that they couldn’t make the call if they had all the info, but the time required to gather and understand all the context would be a second full-time job.

[valenterry]

> The value is that the developer doesn’t reasonably have the context

Sorry, that English doesn't make sense to me. The value is that... the developer doesn't have context? How is not having context a value?

Maybe you meant "the reason"? But then that doesn't answer the question what the value is.

[TameAntelope]

The person I replied to asked what the business value was, so I explained that the [business] value comes from having a dedicated person who understands the context in which the issue is being worked.

[valenterry]

Sorry, still don't understand.

Are you saying that without communicating progress there is no person who understands the context in which the issue is being worked in?

That doesn't make sense to me and seems to be totally orthogonal to any communication of progress.

[TameAntelope]

So do you have a problem understanding or do you disagree?

[valenterry]

For now what you are saying does not really make any sense, so I can't really disagree...

[learc83]

That's why the developer has a manager who is a human who can talk to them and find out what they are working on, instead of a robot that can only process tickets created and tickets completed.