The fastest development process you’ve never heard of
getnashty.com"NO UNIFIED BUG LIST Do not track bug reports and feedback as a team. Nobody will consult that list. Not the developers, and not the people reporting the bugs.
Respond to them in the moment:
I will fix this right now (only if this won’t delay your road-mapped deliverables)."
This may be the worst idea I have read in over a year.
Agreed. That was the part where I rolled my eyes and gave up.
Just for starters, what's a new intern going to work on to get started with the system? What happens to someone's bugs when they leave? Or goes on holiday?
Obviously you’re entitled to your opinion. We don’t have jr. members on our team, but if we did, they’d be assigned a project like anyone else. If the project was a bug, that would be reasonable. This process is for the intern and every other dev to avoid reading a giant list of potentially stale bugs anytime they have a short gap between work. it keeps them working on A) what they were assigned, or B) something small that people have been clamoring for.
Why do you have a giant list of potentially stale bugs?
The policy described in the linked-to article is roughly equivalent to saying that every bug/issue must be passed to someone, who is in charge of that issue, including closing them.
The main difference is that there's a single tracker instead of "personal workload lists".
What happens to the workload on a personal list if the person is unexpectedly out of work for a month?
Now that I've read a bit more:
> Developers will only want to hear the same request so many times, before losing whatever is left of their sanity, and deciding to address the issue.
What happens if the stakeholder's sanity runs out first?
> Why do you have a giant list of potentially stale bugs?
Most places I've worked have a bug log? Priorities balance between new feature development and fixing bugs / tech debt. If a bug isn't high priority, or the feature it was about has been changed or removed, the bug might now be stale - but still exists in a list somewhere.
> The policy described in the linked-to article is roughly equivalent to saying that every bug/issue must be passed to someone, who is in charge of that issue, including closing them.
It's the opposite, it's saying that if the bug / issue isn't easy enough to be solved right then, it needs to be reported again later, or added to the official prioritized road map.
> What happens if the stakeholder's sanity runs out first?
This is a good question :)
I think my earlier rhetorical question came across as one of inquiry.
Most place have a bug log. Some of the OSS projects I'm involved with have bugs I've submitted over a decade old.
My comment was meant to lead in to how a centralized bug system is not the issue - it's one of process. If a bug comes in, and either people accept a bug or close it right away, then it's the same as having a personal work list.
Except that the failure modes, like when people suddenly must be on leave for a month, are less severe.
(With the proviso that some people use personal work lists with a different interface than the centralized system might offer.)