I was introduced to bug tracking software many years back at my second programming job. And by “introduced”, I mean forced – practically at gunpoint – to use it. And boy, did I hate it. Why do I have to put every stupid thing I do, I remember thinking, whether it’s a stupid bug or not, in some stupid system so some stupid project manager can look at my stupid tasks?

I quickly got over it. Within a month, I came to realize how valuable a bug tracking system was in every aspect of software development, from keeping track of the countless little changes to quickly being able to blame everyone else when things went wrong.

To this day, I still think bug tracking is one of the greatest innovations to software development since the IDE. And not only that, I now make sure to “introduce” bug tracking to everyone I work with – developers, testers, designers – by holding a gun to their head until they start using it and like it. Sure, it may not be the most effective tool for non-development tasks, but it works great for us developers, and everyone else will just have to learn to deal. And like it.

Luke Forehand’s manager is big bug tracking advocate as well. Everyone on their team – developers, testers, designers – is required to use JIRA to manage their day-to-day tasks. Not too long ago, their designer, Paul, had simply had enough.

“Seriously,” Paul said throwing up his hands in the middle of a team meeting, “what is with you developer nerds and this whole ‘JIRA Task’ crap!? I have two things that I’m working on. And everyone knows what they are. Why do you insist I log all this in your JIRA bloatware?”

Obviously, Paul had gotten sick of the overhead involved in filling out the issue tracking forms, reporting progress, status updates, describing issue resolution, creating sub tasks, etc. “Well”, the team lead responded, “JIRA is mandatory.”

“But it’s just a big waste of time. I could do the same quality work and be much more efficient with a ‘manual process’, as you’d call it, rather than this JIRA.”

“Fine,” the lead responded, “go ahead and try.”

The following meeting, Paul came back with his own process. He called it “Manual JIRA”.

Needless to say, the team got a kick out of Paul’s process. They did decide to stick with real JIRA, however. And as for Paul, he still grudgingly uses JIRA and has yet to find any value in it.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!