There Are No Bugs, Just TODOs

When people say things like this I often wonder if they worked with a more consistent caliber of people than I have.

There are most definitely bugs, and figuring out that most of them come from a couple of people is critically important to saving the project in the long run.

Knowing that you have 5 bugs and I have 7 is, I will agree, not important. But knowing that Steve has 50? Is really fucking important.

I don't see really see anyone stating obvious truths about bad developers & software engineers (as shocking as it may be to read on HN that there are, in fact, objectively bad developers & software engineers with high-paying jobs at companies whose names you know.)

- they are more interested in making a new thing instead of fixing a broken thing they released

- they often can't remember how they built the last new thing

- that's because they aren't interested in building & documenting a fully working thing with test code from the start

- they aren't interested in data structures or architecture built to be easily maintained or in making scale part of their designs

- they despise being told to fix bugs because it is much easier to write code than it is to read it

I believe some organizations implement Jira thinking it is going to solve their cultural problems. This is magical thinking.

I am so tired of hearing about how terrible Jira is from developers.

It's usually the case that where Jira isn't working it has to do with the way it's configured (e.g., giving too many people access to set priority, setting too many priorities, setting too many components, using components in illogical ways, no one actively managing & grooming queues...)

To implement Jira successfully probably requires more work & effort to get it right than to not use it at all. The point of it is not to eliminate the work of issue tracking. It is to organize the workflow management of moving incredibly complex information from one person to the next. It's pretty great at this if you know how to use it.

"people are trying to fallaciously optimize on cost rather than marginal profit."

Pure truth.

Another great book is The Principles of Product Development Flow: Second Generation Lean Product Development

"Severity" is a measure of how serious the impact of a defect is (Using the term "impact" instead of "severity" can make things clearer). It does not say anything about the priority that should be assigned to fixing it, though it is obviously often correlated.

Severity is an absolute metric, priority is a relative metric.

In general the person who creates a defect ticket sets its severity based on what has been observed. The priority is set later by project management.

> If a particular issue causes a downtime of 1 second every 10 years, it's still downtime, but might not be the most urgent thing to work on.

Exactly. There may be a severe issue but because it happens so rarely it is probably not urgent to fix and thus may be assigned a low priority.

Of course if the issue "prod is down" is both severe and urgent to solve. But after investigation you may find the root cause and determine that it is costly to resolve while occurring only very rarely and thus that root cause issue may be low priority though it is still high severity.

The difference really is useful in practice where the effort and cost of solving issues may not be trivial (large systems and systems involving hardware for example). I have seem severe bugs that were tracked down to ASICs deployed in the field, so very expensive to fix, and for which the fix was deferred to the next product version because it was determined that the issue was rare enough that customers could live with it until then.

So during the meeting, I said: that bug is just a sympthom, the module needs to be rewritten. And I knew what I was talking about.

No, said a senior, we're just going to fix the bug, no rewriting. I said that's your call, but I sure am not going to fix that bug. I can tell you: nobody listened to me.

So he more or less finished the discussion and said: I'm going to sit down with you, and we're going to fix that bug. And we did.

At that point it was the right call.