[lug] Bug tracking systems

Nate Duehr nate at natetech.com
Thu Jan 26 23:14:19 MST 2006

David L. Anselmi wrote:
> Bear Giles wrote:
>> Another difference is that bugs should be unique, request tracking
>> often isn't.
> So?  How does that change the implementation of the tracking system?
> What do bug trackers have that trouble tickets don't because of this?

Bug trackers usually have different categories and business metrics
built in.  But generically you could probably use an application
designed for either in both worlds with customization.

Open-source apps like we typically discuss here are customizable.
Closed-source apps, you usually buy a new "module" for each different task.

An example of a pure ticket system for requests would be something like
RequestTracker.  (www.bestpractical.com)  It has the front-end user
interfaces and built in "stuff" to reply to "customer" requests and
categorize them and escalate them.

Out of the box, RT wouldn't make a very good bug tracker because the
categories and what-not would be all wrong.  But could it be used for
bug tracking?   Sure.

The very best bug trackers would provide views into and interface with
the source repository.  Tag something fixed in the bug tracker, it adds
comments to the source, checks it in, etc... could be done, but haven't
really seen any good examples of it yet.

Examples might be stuff like Agile Software.  They tackle a completely
different problem that many large businesses have... sign-off of
releases.  Something gets checked into CVS, some other engineer has to
know it's there an approve it or double-check the first engineer's work,
another manager has to approve that before it goes to QA, another tech
or two has to QA it separately, their manager has to sign off.... all
the way to product release.  That's stuff a "bug tracker" can sometimes
do in the commercial closed-source world.  Just as one example of
heavily customized applications...

>> For example, a bug might have rendered 01/01/00 as 01/01/;0.  You
>> could have multiple reports, but they should be combined into a single
>> bug regarding date handling.  Once fixed, the bug should never return.

Aggregation happens in ticketing systems for requests also, but perhaps
you need to keep all communication between two customers separate, for

Customer A and Customer B both report a problem.

In the request tracker you handle them and the communication with them

In the bug system it might be the same bug.

Maybe you don't even have or want a direct link between the Problem
report and the Bug other than a manually entered ticket number from each
system in each other's data.  Perhaps you don't want your software
engineers directly interfacing with customers -- you want communication
with your customers to always come from a support group member.

Lots of possible business reasons to split them up... all dependant on
culture and processes people want... and also heavily affected by the
size of the company of people working on it.  Each boss typically wants
their own "realm of influence" and they also want their own tracking and
metrics systems.  Their budgets may come from these measurements... they
don't want a system customized to measure the "wrong" things.

Additionally, most open-source bug trackers are on the web somewhere.

It's rare to see a closed-source company with any direct outside
customer access to the bug-tracking system.

Companies with closed-source code may prefer to have one system as an
internal-only system -- a place where engineers can freely discuss the
problem in the notes of the ticket, but never would that discussion
leave the internal side of the company.

The other system may track the public communication.

>> In contrast you might have a local policy that whoever replaces the
>> toner in the print opens a "trouble ticket" on it.  That ticket is
>> closed when the new toner cartridge is put in the cabinet under the
>> printer.  This "problem" may occur a dozen times per year, and you
>> can't merge it by buying one cartridge to serve three printers.
> You don't think that you might get 7 users put in tickets for the same
> printer being out of toner?  You'd want to merge those.  Likewise you
> might prefer to track a recurring bug separately.  "App cores when I
> click here" might happen more than once over time.  Even if due to a
> regression you might want a new bug, not to reopen the last one.

I don't think we're saying the same application code couldn't support
bug tracking or customer request tickets -- it's probably more a
customization thing and/or a business practice thing.

Companies like Siebel and PeopleSoft make a living out of creating
systems for all of the above, plus sales tracking, plus management
metrics, all with different user logins and views -- but that all pull
from one (or more) back-end databases for displaying that data in a
format useful to the person's job who's logged in at the time.  Another
module for RMA's, Inventory, Shipment Tracking, whatever... they just
keep squeezing money out of the company they sold it to by creating
customized views to the same data in the back-end.  The success of these
applications depends an AWFUL lot on the business knowing EXACTLY what
their own internal processes are and what they need to get those jobs
done before buying such highly-integrated tools -- but it's rare that
any large company really knows all that going in.  They buy the tool
thinking the tool can organize them.  And that just doesn't work.

Show me an office that can be 100% organized and run their business with
filing cabinets and pencil and paper first, and they'll be the ones who
can easily transition to a completely online system and be 100%
successful at it, if they're careful.

The biggest benefit most companies get out of ATTEMPTING to automate
data flow is in finding out exactly what "stuff" is not organized or
written down anywhere, and only exists in someone's head.  Of course,
rarely do CIO's and CTO's budget for "round two" of customization --
that second push to add the stuff you learned wasn't in the database the
FIRST time through.

It's all about organization and how you display the information to the
end-user.  And if the application is more difficult to use than just
remembering the information in your head or covering you wall in post-it
notes... the apps not the right app for your business, because people
will always follow the easy route -- policy or not.

It's also about scale.  How much data can each system handle before
there are massive performance problems?  Many companies choose the
expensive, proprietary route so they can choke the throats of the
software provider when performance issues arise and have someone to
blame for them... or at least they can say "they're looking into it" so
when the vendor comes back and says "your hardware is overloaded for
that system" they've got some plausible deniability that they should
have known that... crazy?  Yeah... probably.  But very true of "big


More information about the LUG mailing list