[sandal]

Well, sure... IF you don't read the essay title, the graph title, the surrounding context, the paragraph directly after the graph, etc.

I plan to fix this when I use this graph elsewhere, but I really don't understand this comment. Is it an automatic knee-jerk reaction because you looked at the graph axes and didn't read the article?

Or did you read it, and have a genuinely hard time making sense of what was going on?

If the latter... sorry about that. However, I'm surprised at just how many people seem to have understood this idea, even without the labels, if it is such a severe problem.

[DrScump]

On both this thread and the corresponding Reddit thread, people voiced on the lack of clarity of the graph elements, in the spirit of helping you clarify and expand on it... and you insult them.

There is a lot of meaning that cannot be determined from the graph. Are any of these tickets redundant/duplicate? Do they all reflect original features or bugs in new features? (Remember, there is no zero-time point on the graph). Do newer defects represent newly discovered bugs that were always there? Do any represent regessions that messed up your installed base?

I can't see any accounting for severity of defect by any metric, e.g.

- difficulty to fix

- span/frequency of customers affected

- severity level, e.g. effects/misbehaviors that produce just visual artifacts, vs. those that crash, vs. those that display wrong results, vs. those that corrupt data

I've worked in (and managed) support organizations in a number of realms of IT, and a sheer "number of defect reports" metric is almost meaningless by itself in terms of determining how to marshal resources to significantly improve the product.

[sandal]

The point of the essay is simply this:

If you're seeing a massive amount of problems in your organization AND you have what appears to be a badly broken prioritization/triage/issue tracking process, you need to fix your triage process before you'll be able to solve the real underlying problems.

There's no situation in which opening 500 issues in four months and only closing a tiny fraction of that amount is healthy, regardless of severity or whether they're feature requests or bug reports, or whatever.

The graph makes that point, and I'll hold the fact that this is on the front page of HN, /r/programming, and lobste.rs as evidence of that point being sufficiently informative and well understood by the vast majority of readers.

I would have updated the image on the first report of the issue if I was able to edit the post, but this is an archive from an email newsletter entry. It is worth fixing, and I will fix it in time for the followup essay.

I am just generally bothered by how incredibly, unbelievably pedantic it is to fixate on this one point and act as if the whole essay isn't valuable because it took an extra few seconds to read the graph.

But hey, this is the internet. We can ignore the larger points and focus on fine-grained details, and that's normal, right?

[callumlocke]

No one is pretending to not understand. The problem is that you didn't label your axes.

[sandal]

I agree that's a problem worth fixing. No issue there.