What's your development experience? I am guessing that you haven't worked on line of business applications for big companies which takes years to develop.

I think it's a mistake to think that Jira and FogBugz are only used for tracking 'bugs'. They are obviously used for that but everyone I know uses them to track everything related to their software. Track features/support questions/infrastructure changes etc.

To give you an example, I am part of 50+ developer team implementing straight through processing for a large hedge fund. This involves developing variety of systems which are highly dependent on each other. Jira tells me that I have 120 items which I need to implement by this year end. Mind you, this is just one system. There are at least 10 more systems like that. I can confidently say that there at least 1000 items in our overall list which we need to work on. You absolutely need a tool like FogBugz or Jira to track them properly.

I've heard this POV before, and I'm somewhat sympathetic to it. Sometimes, it's better just to fix things immediately rather than devote a whole process toward fixing them later.

The problem is that the flip side of fixing bugs immediately is interruptions. If, every time you discover a bug, you have to fix it or forget about it, it means that every time a new bug comes up you're going to have a PM interrupting an engineer. Eventually your engineer isn't going to be able to get any work done, and productivity grinds to a halt. It also puts a big damper on doing any large features, speculative features, hard features, or basically anything that requires sustained concentration for long periods of time.

Indeed, as a tech lead, one of the signals I use for when it's time to introduce a formal process and bugtracker is when the engineers on my team start complaining that they can't get any work done because they're being pulled in too many directions at once. If it's not a problem, then there's no need to slow yourself down with process to fix it. But if it is a problem, it's good to have a strategy that captures all the work that needs to be done and lets everyone coordinate who & when they'll do it.

You've got more than 10 bugs. You just don't know it yet.

But really, "bug tracker" is just a colloquial expression for the more accurate "issue tracker" which can definitely include things like improvements, new features, A/B tests you want to run, etc.

It is possible that their software isn't large enough to have 10 bugs... they could be implementing FizzBuzz.

Where can one get a job as a professional FizzBuzz developer?

I think if a program is big enough to devote a software developer to it full-time, it's going to have at least 10 bugs. Maybe they are small or unimportant or so obscure that none of the users actually run into it, but they're in there somewhere.

In the end its just project management. I want to keep track of the things that still need to be worked on, so I don't forget them. I can delegate work, others can delegate work to me, work that requires other work or sub-steps can be passed around multiple people. The work can be described in detail, more input can be gathered, actions that were taken logged for future reference.

All of that can be achived in many many different ways of course, but software based ticket systems can work quite well in my opinion.

Issue tracking systems are very important, even tracking a handfull is a pain over email or some other non-standardized process.

The way to keep the system effective is regularly close issues that have had no updates for, say 30 days. If someone cares about it, it will be re-opened. If no one notices, well it can be closed.

Good issue tracking system is just as helpful for the coders as it is for QA, PM and the rest of the team. If it isn't, you need to discuss improving it rather then abandoning it all together.

That's a really interesting idea. As a data point, lets look at a healthy, modern, high quality project, what does it use the issue tracker for?

https://github.com/facebook/react/issues

They are using the issue tracker for all sorts of things, and it clearly has value.

Turns out Linus isn't too fond of bug trackers either:

http://yarchive.net/comp/linux/bug_tracking.html

and the kernel seems to be doing pretty well.

Theres not really "bug trackers", there issue trackers. All the micro tasks are created, organised and tracked though to completion. Often visually represented on a kanban board.

Which is a nice abstraction, but really fails with a little reflection. Bugs, shouldn't really have long lifecycles, dependency chains, target dates, etc... Features need these things but don't have wontfix, notabug, multiple branch targets, and discussions about reproduction. Which is why i always like running two different processes and joining the results at release mgmt/source tree level.