
The fastest development process you’ve never heard of - bgnm2000
http://getnashty.com/the-squeaky-wheel
======
60secz
"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.

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

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

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

~~~
bgnm2000
> 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 :)

~~~
eesmith
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.)

