14

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 ?

| improve this question | |
  • Unfortunately, more often than not, management has already made up it's mind. – kirk.burleson Jan 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 Meys Jan 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 Sane Jan 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_now Jan 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. Lowe Oct 12 '11 at 7:01

12 Answers 12

Active Oldest Votes
22

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).

| improve this answer | |
5

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.

| improve this answer | |
5

Everyone else's answers are good. One other aspect occurs to me.

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.

| improve this answer | |
4

You need to show Management that their requirements will be meet.

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.

| improve this answer | |
4

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.

| improve this answer | |
  • The file is centrally shared; why would there need to be additional copies? – JeffO Jan 6 '11 at 13:45
  • 2
    There never needs to be. It just inevitably happens. – Berin Loritsch Jan 6 '11 at 13:49
  • Well, currently we are using a web based solution to edit a shared spreadsheet. So the duplication should not happen. – Sylvain Defresne Jan 7 '11 at 8:05
4

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.

And yes, you can export to (and import from) Excel.

| improve this answer | |
  • 2
    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. – Marcie Jan 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 Gregory Jan 21 '11 at 12:42
2

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.

| improve this answer | |
2

Story time.

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.

| improve this answer | |
1

We are using Atlassian Jira.

It has many reports available like this one: alt text

| improve this answer | |
0

You need to create a spreadsheet that when the manager opens it, all of the necessary reporting data are updated from the app of your choice. If you make it work, there is no argument.

| improve this answer | |
  • It will never work. Whether by accident or malice, sooner or later someone will break the "foolproof" system. – AShelly Jan 6 '11 at 21:57
0

things that can go wrong with a bug tracking spreadsheet on a network share:

  • no one else can edit it when someone leaves it open, then locks the workstation and goes to lunch.
    • the "obvious" workaround is to save a new version for writing. This creates a branch - and Excel is bad at merging. Someone's work will be lost.
  • the document can get saved with hidden rows, an issue gets overlooked for weeks.
  • anything can be deleted and history tracking is marginal. "what happened to the detailed problem analysis I entered last week?"
  • it's easy to add values to 'restricted' fields. "How did this bug's severity get marked 'Epic Fail'?"
  • cut and paste overwrites formulas. A calculation can easily become a constant.

I've lived through all of this. And we still managed to deliver... It was only three months late and cost thousands of unplanned overtime hours.

| improve this answer | |
0

"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. :(

| improve this answer | |
  • I already tried this argument. Didn't win, as I was told the price was not the problem. – Sylvain Defresne Jan 7 '11 at 8:04
  • I guess you're stuck with the "Superior In Every Regard" argument. :-) – Nick Spreitzer Jan 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. – Keyo Jan 7 '11 at 13:59
  • That's why you need to follow up "it's free" with "and it's awesome". – Nick Spreitzer Jan 7 '11 at 21:13
  • 1
    Just don't bother to mention free – Murph Apr 26 '12 at 9:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.