How do I convince a manager we need bug tracking software?

Question

Good day all, I'm the "lead developer" for a major Excel based application that handles the production of a few mine sites. It talks to a bunch of databases, tries its best to help out users, and generally clunks along just fine through a mix of Solver, VBA, and in cell formulas.

Our development team is tiny and is composed entirely of non-software folks. I've done a bit of reading and am convinced we need some easy (easier) way of bug tracking that goes beyond simply commenting out code in the VBA source.

I'm well aware that bug tracking, perhaps followed by its cousin code control, will improve my life immeasurably but have a hard time finding the proper phrasing to convince management that this is so.

Can anyone offer up advice, or present a quick rundown on the business value created by proper bug tracking and control?

Thanks!

Answer 1

What currently happens if a bug is reported but you can't fix it immediately?

How do bugs even get communicated?

What testing do you have in place to make sure that a bug has actually been fixed properly?

Where is all your code currently stored?

I would basically come up with scenarios where your current situation would fail badly:

• One person starts fixing a bug, but then falls ill
• You find that the fix for a bug doesn't actually solve the problem
• You find that the fix for a bug breaks other things, so want to roll back the code
• You want to report on what's happened in the codebase in the last 3 months (e.g. for performance reviews)

I'm sure you can think of more, knowing your situation better. Depending on your location, there may well even be legislation which is easier to comply with when you use proper project management tools.

Answer 2

Bug tracking is a good way to communicate and solve the problems efficiently. You can introduce your manager a bug tacking application can reduce lots of hassles caused by miscommunications among team members. Meeting is not a place to raise bugs, since debuging is part of development process, bug tracking is definitely useful.

Answer 3

You can start with the Joel Test. And then Painless Bug Tracking. IMHO, version control is more important than bug tracking. I think you can version-control excel sheets and VBA scripts. You need nothing fancy, maybe subversion; TortoiseSVNis a nice Windows interface to SVN. For bug tracking, you can use bugzilla. We use fogbugz, which is a bit nicer, but you can go a long way using free tools. Good luck.

Answer 4

Ask him and the next 3 people how many bug there are in the current project. If the number varies widely use that to point out that bug tracking would help you know where the project at. (OTOH if everyone says the same thing, it doesn't help you a wit).

Answer 5

Make a business case: how much does it cost to buy bug tracking and code management utilities vs. how much will be lost due to developer resources being wasted fixing bugs twice or not at all (because they get lost)?

When dealing with managers, money mostly is the only thing they understand. If something is cheaper, they will probably go for it.

All that being considered, if your management does not like to think long term and refuses to buy these tools, you can probably switch employer. You know, sometimes the grass is greener on the other side.

Answer 6

Sounds like my mate who works for Origin Enery (gas company).

I would go to your boss and say:

"We need some bug tracking and source control software. Bug tracking to impove the robustness of the software, and source control to back up to older versions quickly in case anything goes wrong"

I guess the biggest thing for mines is the potential for lost time mining. The cost of bug tracking / source control is bugger all compared to the cost of one stainless steel bearing on a truck. (I had to buy one). So I guess the thing they would most want to hear is that if you get source control you can immediately and reliably back up to an older version if necessary and therefore not lose any production time.

Or probably the best bet - just use the free tools and don't even bother telling management.

Answer 7

If you have a "major Excel based application" its probably going to be difficult to persuade your management of anything sane, sensible and organised.

:-)

Answer 8

It could be easier for you if you bring a free bug tracking system such as Bugzilla.

A good saying I know is:

It's easier to ask forgiveness than to ask permission

A while back I worked in a small startup company and both the CTO and the lead developer where against using it (too costly, to hard to use etc.).

What I ended up doing is taking an old machine, installing Linux & Bugzilla on top of it and started using it with the QA instead of sending emails back and forth (the de-facto company's"bug tracking system").

After a while I introduced this idea to the whole company and it was embraced by all - I guess having a successful pilot helped.

I've left that company about 3 years ago and they still use the bug tracking system I deployed.

Answer 9

don't forget you can easily set your own error tracker ...

The first bug tracker should be somewhere in your code. You have to implement a generic function to be added at the end of each procedure in case or an error (you can have this kind of lines automatically inserted to your procs by using a VBA add-in such as MZ-Tools):

Public function ...
On error goto error_label:

...
...
...

Exit
error_label
errorFollowUp (your parameters: who, which machine, which file, line number, etc)
End Function

This error follow-up function can do something like adding a line in an error table somewhere on your network, or add a line to a log file, or whatever.

... and allow the users to share their problems

this can be done in a very nice way with uservoice.com ... just like SO does.

EDIT: by the way, as you are working on Excel, I am in the process of explaining how and why we developped an access user interface with an Excel-like flavor for our database. You can check it here.

Answer 10

Well, as one other post already said it's hard to convince some manager that is not really in the software business to use fancy tools and stuff - the manger that give you notepad to write code in I suppose.

I don't think you can throw a paper with a ROI on it (they exist and you could probably find some with a proper label on it)

I think you should get to a much more basic psychology(?) level and reason with him. "We start to have problem, bla bla, I've heard about this kind of thing called bugtrack/version control. It would let us as a company develop a collective memory of which bug we have, which bugs we are working on , bugs that already are fixed but the user don't use the latest version. It would be easier to recruit new developers because they can use this collective memory and get more knowledge about our product faster. "

I'm sure that you can by using words that are not software related (like bugtracking and version control) but some 'memory' keyword (archive, knowledge database) to get to a point that the manager can see by using "plain common sense" that this is a good idea.

Answer 11

Why your team need a bug tracking system?

1. The bests Bugtracking Systems are free. You don't have to waste The Company money buying licenses.
2. It doesn't need bigger servers nor to much maintenance tasks. Just rember to make a daily backup.
3. It allows you to manage your programmers.
4. It allows your Manager to prioretize witch bugs/features must to be fixed/developed first by your team.
5. It allows your Manages to tell to her boss how de developing is just progressing.
6. Normally, you can use a Bugtracking System as simple TRAVEL TICKET SYSTEM. So you have 2 tools in 1! One for your Manager and other for you!
7. It allows your Manage, you and your programmers to see what are everybody are working on.

During 8 years i used to use Bugzilla, and since one year ago i'm using Trac. Both of them are good choices.

IMO the point here is to use the Bugtracking System as Travel Ticket (for your Manager and you) and as Bugtracking (for you and your programmers).

Answer 12

Start with making the problem visible for management. No need for software.

Put a notecard on the wall for each bug. Put a short description, reporter and the entry date on it. Use a (color) marker to show priority and fixed bugs. Depending on the story you want the notecards to tell, order them by age, priority, reporter or developer.

After making the problem visible, you might want to talk about solutions, possibly involving software.

Answer 13

Install a free bug tracking system and start using it. I have used Gemini on many occasions, and it has done the job very well. It's free for up to 5 users.

Answer 14

'go stealth'

what does that mean? just go ahead and start using a bug tracking system yourself. why do you need to convince people to do something which everyone in the software industry accepts to be best practice.

this is one of the techniques discussed in 37signals book Getting Real (an excellent book by the way).

i have done this now a few times at companies i have arrived at which didnt use bug tracking systems. but i do have to admit, i have been questioned about it by senior management (which i defended my actions to their satisfaction). its more a case of being viewed as presumptuous.

LM

Answer 15

Show your manager this thread!

Answer 16

i would also add, dont send your manager emails with links for her to read. or print things out and leave them on their desk.

youre better off saying "can i do a 30 minute presentation for you on Wednesday?" or "can we go out for lunch one day this week and do an informal chat about bug tracking systems?"

LM

Answer 17

One way to sell the idea is immediately after you had a failure that bug tracking would have fixed or helped. For instance, customer a reports a bug in June and we promise to fix but we couldn't get to it right away and since we didn't have a tracking system, the whole idea got forgotten. Six months later the customer cancels because the bug is still there. You get the idea, point out one or more problems (persistent ones even better) that got lost in space because you didn't have a way to document bugs or couldn't prioritize them, etc. Real problems they have had to deal with in the past (especially the immediate past when dealing with the issue is still a painful memory) are far more powerful than a list of what might go wrong. If it is performance appraisal time, you could point out how much easier it would be to do appraisals if there was a record of waht you did. If you need more people point out how much easier it would be to justify if you could show what the backlog currently was. You could point out that your customers (internal especially, you may not want to give external customers the right to see reported issues) will be happier if they can report problems and then see what is happening to that report.

Answer 18

I don't understand. Is the issue that you're requesting funds to set up bug tracking software? Otherwise, what could possibly be the pushback to "I want to install some free software that will help us manage our time, work more efficiently, and quantify progress" ?

Answer 19

I agree with some others in this thread - just install one and start using it. Put some thought into making sure it will scale to all the developers, testers, etc. You might want to also use the "free" ones to remove that aspect of barrier/use.

Don't preach, don't lecture, but do show people if they are interested. If people email you with questions, etc, you can respond with links to the cases int he tracking system.

Also link to it with your version control commit comments. (are you using version control?)

Read the excellent suggestions and basic bug tracking information provided by Fog Creek. (this is relevant to any product you use)

http://www.fogcreek.com/FogBugz/docs/60/topics/basics/Thebasicsofbugtracking.html

http://www.fogcreek.com/FogBugz/docs/60/topics/basics/Tentipsforbugtracking.html

http://www.fogcreek.com/FogBugz/docs/60/

Answer 20

I suggest to find article "CAN PIG RIDE" about logging bugs into issue/bug trackers. And just in case you can subscribe to a new online bug and issue tracker