Hacker News new | ask | show | jobs
by commandlinefan 2022 days ago
I hope you're being sarcastic.
2 comments

Probably, but to represent the non-sarcastic point of view, it comes down to "[person] in the room" syndrome[1]. Spending 2-3 weeks on a bug is never good, if you're not communicating progress, and one way to communicate progress is to break down the work into smaller chunks.

Does it literally have to be individual JIRA tickets? No way, but going off for 2-3 weeks doesn't give the business the insight it needs to in order to wisely invest time/effort into work being executed.

[1] https://medium.com/machine-words/a-guy-in-a-room-bbbe058645e... (I thought Joel Spolsky said this but I can't actually find the original source, if anyone has it I'd appreciate it!)

> 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?

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.

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

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

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.
Of course.