News Stay informed about the latest enterprise technology news and product updates.

How to drive developers crazy with issue tracking

By careful use of an issue-tracking system, a crafty manager can be sure to drive a team of developers crazy. Mike Gunderloy outlines the steps in this modest proposal. A sampling: "Any bug you enter should always have the highest priority and severity the system allows, and the fix should be due as soon as possible." If not sooner!

There are many ways to drive developers crazy. Of course, some would say that it is a very short trip to drive most developers crazy in the first place, but by careful use of the team's issue-tracking system, the crafty manager can ensure that the trip is swift and permanent. This knowledge is already widespread among experienced managers. For those of you who are new to the business, these tips may help point you in the right direction.

The first fundamental gambit is to report bugs with insufficient information. Remember, there are three essential parts to a good bug report:

  • The steps to reproduce the bug
  • What happened
  • What should have happened

Under no circumstances should you include all three of these parts when you enter a bug into the system. Be sure to vary which piece you leave out, forcing the developer to actually read what you did enter and then come back to you for clarification. This will increase your importance in the organization and emphasize how essential you are to the process of getting the software built.

For example, if you lay out the repro steps and the outcome, don't specify the expected behavior. This works best when the bug is in some very obscure corner of a spec -- last discussed months and months ago -- with which you can then demonstrate your intimate familiarity (saying, for example, "Oh, I'm sorry. I thought you knew what it should do.").

If the bug is very complex, supply the repro steps and expected outcome, but don't bother with what actually happened; this will make developers spend time setting up the case on their own machines to find out what's going on. And when you want to emphasize the value of your own time, cryptically describe bug behavior, saying "sometimes the screen is blue instead of green," with no indication of how you got to that state. That can help you to present developers with unsolvable problems.

More on application testing

Testing and Debugging Learning Guide

Test and debug an ASP.NET app: Chp. 4 of Murach's ASP.NET 2.0 Web Programming with C# 2005

Most issue-tracking systems assign ownership of a bug to one person at any given time. You can take advantage of this in several ways. One is to wait until a bug has been assigned to a developer for long enough for them to be making serious progress on it -- say, three to five days -- and then swoop in and make some arbitrary change. Grab the bug back long enough to edit the proposed resolution: "On second thought, we should only show six days of output, and it should be grouped by City instead of Customer, and it needs to have graphs." Timed properly, this maneuver can force the developer to throw out a substantial amount of almost-finished work. A second tactic is to assign ownership of a bug to a developer who can't do anything about it. This will inflate their bug count while deflating yours. If you're waiting for input from an outside vendor who only communicates with management, where better to park the bug than on the developer's desk?

Choosing good bug titles is an art. Remember that the developer will often be working from a long list of titles and trying to scan for important issues. Why should you do their work for them by making it easy? "Fix this," "Due Tuesday," and "Bad Data" are good titles that will make them actually read your bugs.

And remember, you want to make sure that developers treat your bugs seriously. Any bug you enter should always have the highest priority and severity the system allows, and the fix should be due as soon as possible. This is especially critical if there are other testers and managers also assigning work for the same developers you're using.

Don't bother searching for duplicate bugs before you enter new ones. The developers should know the product well enough to know what's already been reported as a bug. Besides, if they see the same bug reported four or five times, it will encourage them to fix it sooner.

Finally, remember that the issue-tracking system is there to aid you, not to constrain you. Why should every bug go into the system? Make sure you mention some issues in meetings, phone calls, instant messenger chats, and e-mails that are not documented anywhere else. If you're too busy to use the system, you can count on your minions cleaning up after your mess.

By keeping these few simple tips in mind, you'll be able to use your organization's issue-tracking system for its intended purpose: as another tool to remind everyone that managers are in charge and everyone else is less important. Yes, it can also be used to track and manage bugs in the software that developers are producing, but that's strictly secondary. And if a few developers go crazier in the process -- well, who will notice?

Mike Gunderloy is the Senior Technology Partner for Adaptive Strategy, a Washington State consulting firm. You can read more of Mike's work at his Larkware Web site, or contact him at

Dig Deeper on .NET Framework security best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.