Bug reporting and sociopath developers

Bug reporting reminds me a bit of customer service interactions. They
can be easy matters where everyone knows their role in the process and
does their fair share of the work, or it can be a lopsided affair with a
whole lot of hissing and spitting. You might think I'm going to single
out open source, but I'm not. This applies to internal corporate
projects just the same.

Here's a bug report to consider. The title was something like "random
crashes", and the body was approximately "The program crashed several
times". That's the whole report. Imagine you're the developer and you
see that pop up in the queue. Where do you even begin? You have a
number of options now.

You could punt the report back as "insufficient data". I've seen places
which set up an internal document or wiki page with a whole manifesto on
"how to report bugs properly". Sometimes people set up shortcut links
to these things, and while some of them might be "go/moreinfo", others
might be downright hostile.

Let's say the program in question accesses a server, and you have access
to those logs. Maybe it keeps track of every request, and you can
filter it down to the ones which failed. Then you can correlate those
failures with the time when the bug report was filed. Perhaps you have
some kind of magic which lets you see the reporter's IP address, and you
can see the same value in the logs.

At this point, you probably could dig in and try to figure it out from
those log entries. The assumption here is that they are actually
related to this bug and aren't coming from something else entirely. If
you get lucky, you might be able to resolve this all without going back
to the original requester for additional information. If nothing else,
that removes a few more round-trips and interactions with this ticket.
You still probably should remind them what happens when insufficient
data is provided: it takes longer to resolve, and the actual problem
might be missed entirely. There might also be a deprioritization
penalty applied to "encourage" better behavior if it continues.

When it comes to being a user and reporting problems, I have to admit
that I look at past interactions with a given set of developers. By
that, I don't just mean my own interactions, but rather how things are
handled in general. Many projects have bug trackers which make this
rather easy. A few minutes of clicking around can give me a good idea
of what will probably happen if I bother to report something.

There are many things which can be learned by reading past interactions.
First, how quickly do things happen in there? This applies both to
overall bug lifetimes and the general latency within a bug. If there
are many bugs which have been open for years, you might not want to make
plans involving your request being handled. Likewise, if it takes a
week to get responses to any given update, expect it to take a very long
time.

Then there's the matter of ability. Who's handling the bugs? Is it a
volunteer who has the best of intentions and a lot of heart but not
much knowledge? When they do get involved, do they understand what's
going on, or is it like pulling teeth to make them see a genuine
problem? How hard is it to get the attention of someone who will get
it right the first time? Does such an individual even exist? It's
possible that nobody like that exists on the team any more.

Worse still, it's possible that nobody like that ever existed
on the team. Just because a project exists and sort-of works doesn't
mean that anyone understands it, and that includes the creator. If they
out-clevered themselves by writing code they can't even maintain later,
then you might see this exact situation play out in the bug tracker.

Next, how about attitude? What is the environment like in the bug
tracker? Are people generally civil? When it stops being civil (and it
will at times, no matter how many rules are in place), who starts it?
Who escalates it? Who ignores it? Who redirects things?

If bad attitudes and general hate tends to come from the developer side
of things, that might be a cause for alarm, especially if there's no
apparent reason for it. If it's an isolated case, perhaps between two
specific individuals, that's one thing. But, what if it's a number of
distinct bug reporters, and regardless of how they present things, they
all get the acidic response from someone on the dev team? To me, that's
a red flag.

Part of the attitude question is overall cockiness. When a problem is
reported, does someone hop on it and immediately deny it? Do they do
this even if the user presented a lengthy case?

Let's say the user is plucky and won't just give up, and they fight to
make their point known. Then the cocky developer eventually gives in
and patches the code -- in other words, there was a problem,
since a patch had to be applied! What happens then? Do they mellow out
a bit for next time, or do they stay just as cocky as ever?

I've seen that last one play out in a bunch of bugs which were handled
by the same individual. The pattern is generally like this:

User says this kind of venom doesn't help and it doesn't matter since
it's still a problem.

Developer points at a patch from a recent release.

User says it doesn't fix all of the problems, and their
original report is a corner case not handled by that patch.

Developer patches the code and updates the bug with a pointer to it.

User goes away. Satisfied? Happy? Looking for alternatives, perhaps?

---

Notice the developer never says "Oops, I was wrong" or anything of the
sort. The bugs tend to just get a notice of a patch being applied and
then just go silent. There's never any sort of closure on a human
level.

This happens over and over. I'm beginning to think that some people run
these projects and maintain bug reporting systems just so they can (try
to) play the part of an evil overlord. I bet these are people who would
be shunned in the real world for such antisocial behavior, but the
computer lets them have an endless supply of fresh victims. These are
people who are at the mercy of the developer's delusions of power, and
they have no idea what's about to happen.

Look at it this way. If someone at your local market starts treating
you like garbage, you can tell a few people on your way out. You can
directly influence people who are on their way to possibly deal with
that same individual. This doesn't work quite the same way on the web
because you probably can't intercept people on their way to the bug
tracker. They're going to arrive without any sort of warning of the
kind of sociopathic behavior which may lay ahead.

Sure, there are "out of band" venues for reporting such trouble spots
like reddit or Hacker News, but they aren't in the direct path of
traffic heading to the trouble zone. It's not like you can run a picket
line in front of a web site, right?

...

I have a final point to make about this in the form of a thought
experiment. Imagine a project with a belligerent dictator running the
show. If you already know one, use that. Otherwise, make one up.

Got it? Okay, here we go.

Let's say the program manages to accomplish a few useful things. One
day, a particularly talented user downloads a copy and tries to use it.
It mostly works, but they run into a problem with it. They look into
it and see that a fundamental mistake was made. It's no big deal to
fix it, and they do exactly that to their local copy.

Now, this talented user knows about the reputation of the dictator
running this project, and decides it's not worth the trouble to report
it. Reporting it would be akin to saying "you suck at design" in the
eyes of the dictator.

While it's probably true that the dictator does suck at design,
the talented user wants no part of the drama which would follow such a
report. There is absolutely no benefit to lighting that particular
fuse. And so, the problem is never reported, and the patch is never
conveyed upstream. It effectively becomes a private fork limited
to the talented user's systems.

The real losers here are the ordinary users who are unable to fix this
problem themselves. They are at the mercy of the dictator to do
something about it, and that's unlikely to happen since it would amount
to an admission of ignorance or incompetence. Status quo reigns
supreme.