In our company, the developers want to use a proper bug tracking tool to manager issues in our application. The management however insists on using a shared spreadsheet (formeerly a shared excel file, now a spreadsheet on a web base solution allowing concurrent access).

Their argument is that the spreadsheet allow them to have a more highlevel view of the state of the project as they can see how many bugs are open with a quick glance. This also allow them to see who is working on each bug, and get estimation of the time required to close them all (as developer are required to fill time estimation of the bug they are working on).

As you can understand, this is not really practical to use for the developers (bug tracking software were invented for a reason). So how can I advocate bug tracking software to ease the work of the developer ?

As a bonus, which software would you recommend that would allow the management to be able to get their feedbacks (number of bugs opens, who is working on them, time estimation) with a high level view ?

Unfortunately, more often than not, management has already made up it's mind.
–
kirk.burlesonJan 6 '11 at 13:23

4

Show them eusprig.org/stories.htm. Or even just the 24 million loss of TransAlta due to a copy-paste mistake in EXCEL. Heck, you don't want to use a program that allows anybody to change about just anything in an absolutely uncontrolled manner. The worst tool for management is Excel, and that is proven numerous times. This is also an interesting article : skillsportal.co.za/page/training/articles/…
–
Joris MeysJan 6 '11 at 13:55

Do you at least have version tracking turned in in the Excel file? If not, you might as well use a white board.
–
Wonko the SaneJan 6 '11 at 15:09

Mantis is free, you can install it in about 2 hours, and it gives you stats and things. As a bonus you can easily allocate bugs to releases & developers, change states, impose workflows, log comments and commentary, attach emails or other files. The list goes on and on. A spreadsheet is primitive, uncontrolled, inefficient, and far less effective. As we as prone to human error and leaving no audit trail.
–
quickly_nowJan 6 '11 at 22:24

2

open the spreadsheet on an unused workstation so that it's locked for editing, turn off the screen, and pretend you don't know what's wrong when no one can update the spreadsheet. ;-)
–
Steven A. LoweOct 12 '11 at 7:01

12 Answers
12

So how can I advocate bug tracking software to ease the work of the developer ?

Given this statement:

the spreadsheet allow them to have a more highlevel view of the state of the project as they can see how many bugs are open with a quick glance.

you need to be looking at systems that have reporting tools that effectively allow the creation of spreadsheets in "real time" (or as close to it as possible). When you find one of these explain that having the developers use a "proper" system will mean that the data they're interested in will (hopefully) be more accurate and up to date (for example).

Which version of the spreadsheet's up to date? Who has that spreadsheet?

Any decent bugtracker will do what a spreadsheet can, only:

will email relevant parties when something changes

provides a single canonical source of up-to-date info

allows for summary reports, to give high-level views of the state of the project

For my personal projects I use Mantis (just because it's really easy to set up). Work uses Trac with Mercurial integration.

Mantis provides things like number of bugs open/closed/assigned out of the box, and I imagine most bugtrackers would. I don't know about time estimation, because I haven't bothered looking. Trac (or the installation here at work) does have time estimation, and it's easy to write a custom report that will, say, sum the estimations per milestone.

What about security around the spreadsheet. Shouldn't management be concerned that any random developer could accidentally hit the CTRL+A, DELETE buttons and really mess things up? A proper bug tracking system would not allow for this kind of data corruption. And that doesn't even account for malice. What if a particular developer wanted more credit and started reassigning all of the defect fixes to himself. A real system would have an audit trail where that kind of thing would be noticeable. A spreadsheet would not.

Their argument is that the spreadsheet
allow them to have a more highlevel
view of the state of the project as
they can see how many bugs are open
with a quick glance. This also allow
them to see who is working on each
bug, and get estimation of the time
required to close them all (as
developer are required to fill time
estimation of the bug they are working
on).

So set up a dummy system and show them with demo's that they can get this info just as good as and maybe even better than using a Spreadsheet.

So far everyone's come up with similar and proper responses. There is one important aspect that wasn't spoken towards yet. In order to track bugs and make sure nothing slips through the cracks, you need two things:

Good reporting, both summary and detail--this can be searched later on

Everyone needs to know where the most up to date copy is.

In almost every environment that advocates using an Excel spreadsheet, there are different copies of this spreadsheet on everyone's machine--and none of them are the same. This makes the process of reviewing progress extremely difficult and counterproductive.

A centralized server such as Trac, RedMine, JIRA, Mantis, or whatever you want takes care of both of those problems. At that point, its a matter of what fits your company's needs best. Depending on your environment, these tools can integrate with your IDE just like your version control system (Eclipse has this feature). That makes working through your assigned bugs a lot easier.

I don't know your environment, but for Visual Studio users, I highly suggest TFS. It integrates both source control and issue tracking, with full reporting capabilities. It also offers layers of authority, full history tracking (i.e. who updated the bug when, and if set up, why), allows you differentiate between a "bug" and an "issue" and an "enhancement" and whatever else you'd like, and completely integrates with the Visual Studio IDE. It ties together a bug with the code that was checked in, which can be tied to specific builds. And a whole lot more.

I've used lots of different source control systems (VSS, SVN, TFS...) and lots of bug tracking systems (Custom proprietary systems, Tracker, SharePoint, and yes, even Excel), but for my money (and it is a good chunk of change), TFS is worth the investment in money and time.

We use Team Explorer with TFS, where you can literally open the Bug List as a spreadsheet, choose "Refresh" from the Team menu, and there you go, latest bug list in Excel but with a full bug tracking system behind it in TFS.
–
MarcieJan 6 '11 at 14:48

1

Plus there is a "dashboard" thing (based on Sharepoint) that includes document libraries that appear to have spreadsheets in them. When you open the spreadsheet it is populated by pulling a query from the repository. The manager can update pri, effort alloted, and whatever else they want using Excel, then click Publish and it goes back into the repository. They get all the Excel-ness they want while the devs get all the associate-checkin-to-WI, add-a-screenshot-of-the-problem, see-my-tasks-in-Visual-Studio, etc-ness that they want.
–
Kate GregoryJan 21 '11 at 12:42

To help sell the transition to a proper issue tracker you should try to find out what issues management has with your current system (there is bound to be a 'it would be nice if...') and see if you cant scratch that itch for them.

Reading the management's arguments

Their argument is that the spreadsheet allow them to have a more highlevel view of the state of the project as they can see how many bugs are open with a quick glance. This also allow them to see who is working on each bug, and get estimation of the time required to close them all (as developer are required to fill time estimation of the bug they are working on).

I agreed with all of them and every single one is met by JIRA (I mention JIRA only because it is what I use, I'm sure there are other worthwhile candidates)

You need to emphasize that with a tool like JIRA, not only will they retain all the advantages of your current setup, they will also get a many new advantages.

Couple months ago I came back from a week's vacation to find my whole company turned on its head. A project that another section of the development department had been grinding on for months was suddenly a white-hot-urgent priority, and the whole team was pulled off of what they were working on to churn the thing out. In the meeting that day, the owner of the company asked us to knock out a couple of the pieces that day and the rest the next day and we'd be in good shape.

Six weeks later we finally delivered that thing, after pretty much nonstop work/sleep cycles.

Our metric for "finished" was that the client had no more feedback. New and exciting things would turn up on each version of their feedback (delivered to us by email) that had never turned up before, and every word that they said was instantly part of the spec (justified with the phrase "let's just get it done").

Late one night I had just totally freaking HAD IT with managing bug reports by email and printouts-with-checkmarks. I installed Mantis on our test server and loaded the feedback document I'd just received for my section into it. I set up my manager as a user and let him start getting emails from it as I closed issues.

Within about 6 hours I had the whole team on it. The PM was filtering client emails into Mantis, developers were claiming and working issue lists. Even better, they were able to request clarification and communication inside the system, resulting in a paperless paper trail of details about each item.

The next day they asked me to Tech Lead the rest of the project. It was sort of like being handed a live grenade, but I took it and ran with it. Two weeks later we finally exhausted our client's ability to yank our nose-ring, and put the site into production. Mantis is now how we manage bugs, and might become how we handle feature requests from the beginning of a project.

TL;DR: Install it your own self and start using it for your own stuff. Let it prove its worth on its own.

BTW, this is the same policy I'm following about version control. We use Subversion under a lock-required policy, because my manager doesn't trust file merge. That's fine, but after I check out a SVN project, I immediately make a local git repository of it for my own use in development.

"It's FREE!" is usually a pretty good argument. Pivotal Tracker is free, requires no installation, and could very easily give your managers a better high-level view over things than is possible with a lowly spreadsheet.

Edit:

Much to my annoyance, it was just announced that Pivotal Tracker won't be free for much longer. :(

I already tried this argument. Didn't win, as I was told the price was not the problem.
–
Sylvain DefresneJan 7 '11 at 8:04

I guess you're stuck with the "Superior In Every Regard" argument. :-)
–
NickJan 7 '11 at 8:22

Actually a lot of people will associate free with crap. I suggested a free alternative to something and my boss replied "We only want the best" or something similar. In the free market this is usually true, but may not always apply to open source of course. Not many people really understand the open source model, if it's commercial and free it will have strings somewhere.
–
KeyoJan 7 '11 at 13:59