Apps

Poll: What kind of bug tracking do you use?

Do you use Team Foundation Server, Bugzilla, a homebrew, a shared document, or nothing at all for bug tracking? Let us know by taking this poll.

Different organizations have different needs. The bug tracking tool that a big shop uses may be overkill or clunky for a smaller one. Some developers feel comfortable just using a shared spreadsheet or other similar system; some places just write their own to fit their needs. I've also seen plenty of environments where no one knows what they are doing for bug tracking, other than jotting notes on the back of a napkin.

J.Ja

About

Justin James is the Lead Architect for Conigent.

22 comments
dmc9
dmc9

We use http://trackjumper.com because it's easy enough for our clients to use without hand-holding. Prevents a lot of effort duplication, confused emails, etc.

sysop-dr
sysop-dr

Hi, I know that this may seem to be a strange answer but the answer is, it depends. Software quality assurance is an exercise in risk balancing. So why use different types of bug tracking, because they fit with the other tools you are using and some tools provide more coverage of QA requirements than others do and sometimes the heavier ones provide to much control and the light weight ones to little. For really high qa projects we use MKS Integrity and MKS Source in eclipse and with Ada or C++. On the other end of the scale we use a local install of sourceforge and cvs. For projects that are in Visual Studio, c#, j#, asp.net we still use MKS sometimes and other times SharePoint webapps. I've used mylyn and git in eclipse for python and c++ and java. (And php, fortran etc.) I have one group still using pvcs and a foxpro database. (Sigh, at least they are not using upeml anymore.) For our developers targeting WebSphere and JSP/Java they use the rational suite and Rational Application Developer. So the question to the answer is not what one do you use but rather which ones do you use and why?

apotheon
apotheon

These days, I use "other" -- in my case, a service. I find that Bitbucket's issue tracking system is excellent. If I had a need for my own application for issue tracking, I'd want it to work somewhat like Bitbucket's issue tracker, in fact. The only thing it's missing, given my needs right now, is inclusion in the Mercurial version control history itself.

Justin James
Justin James

... and I think that it is WAY too heavy for our needs. Basically, the big "get" in it is that it is easy to tie work items/bug tickets to source code check ins. We aren't using any of the other SCM features, and the bug system in it is pretty poor in my opinion. I would love to shift to something like Mercurial + FogBugz to get the same level of functionality without the headaches. The TFS workflow is a mess, especially once you want people developing in isolation, where a system like Mercurial works like that by default, TFS forces you to be constantly branching and making changesets and stuff and then trying to merge back into the main branch, it's a mess... J.Ja

Slayer_
Slayer_

It works well too, the corporate people are trying to get us to move to "OnTime" but it lacks the features we have in ours. Ours also has the ability to compile patches, track client information, and send updates as well as record which clients have installed the updates. I think for a development department, homebrew is the best way to go.

h8usernames
h8usernames

We developed a Cloud based task management system that works remarkably well for bug tracking of mid-sized applications and teams. This allows not only the bug information be submitted but assigns it as a task to the group and in turn can be assigned to a specific developer to resolve. Notifications are sent based on criteria, e.g. 24 hours in the queue but not assigned or overdue to be fixed. Where it may not allow for many of the advanced tools we only have 12 developers and about the same number of apps so this works well for us. I have seen advanced systems destroy smaller companies from the inside because where there is a lot of power it is in the wrong hands, bugs get lost, co-ordination doesn't happen as easily, etc. I have also seen smaller systems cause problems when a company grows, they lack functionality to manage what needs to be done and who needs to do it often, when the systems cannot grow the companies often see it as 'we have always used this, so why change now after 3 years of it working' In summary, many companies need to learn to change to the right system when their needs change, not get stuck into the 'we need everything on offer even when it is overkill' or the 'we have used it for so long' mindsets. Having an application built in-house means it can be scaled to suit. Well for us this is the case anyway.

apotheon
apotheon

How do you think it compares to Bitbucket's issue tracker?

Justin James
Justin James

FogBugz integrate bug tracking with Mercurial. I keep meaning to look at it, I think it could very well replace TFS, if I could get the approval for such a project... J.Ja

jmzamudio
jmzamudio

Do you actually use TFS? I mean TFS is a pretty expensive solution and if you use it only for bug tracking you are wasting your money. Another point is that TFS does not force you to create branches, you create the branches you need, if you have branches you don???t need what is broken is your process, not the tool.

apotheon
apotheon

People talk about how great Visual Studio is as an IDE. I'm not really a fan of traditional GUI IDE applications, but for those who like them I'll accept that it's a good one for argument's sake. Even so, and even if I liked GUI IDE applications, I think I would avoid Visual Studio. The reason is that what the IDE core provides is only a small part of the complete development environment; there are other tools that must tie into the IDE to make the IDE worth using for a decent development team (or lone developer, for that matter). For that to work, you need tools that can tie in with it, and do so very well. Unfortunately, all that development toolset ecosystem that ties in well with Visual Studio sucks. Anyone who doesn't loathe TFS, Visual SourceSafe (terribly misnamed), and other such tools probably has no experience to speak of with alternatives that are any good.

apotheon
apotheon

I'm aware of FogBugz, but at the moment I really don't have the need for it nor see much potential need for it in my near future, so it's not on my list of things to check out. I am, however, considering some trial use of the Fossil DVCS. It has built-in issue tracking, and can be run as a CGI script, among other benefits. I just happen to like the centralized social networking aspects of Bitbucket so much that I haven't been able to tear myself away from it long enough to give Fossil a fair shake.

Justin James
Justin James

... my employer has it (we get it for free as a Microsoft partner). I've been using it for years. We actually use it primarily for source control, the bug tracking is a bonus. I may add, it's bug tracking isn't really good. I know it doesn't *force* you to branch, but if you want to do anything useful with SCM besides track individual file changes/checkins, branching is pretty needed. The difference is, working with branches in TFS is painful, working with them in, say, Mercurial, is a joy. J.Ja

Slayer_
Slayer_

It even once decided to dump all over our data, and to this day, it can't verify itself without doing it again, we just run around with it corrupted now.

apotheon
apotheon

A single person maintaining software for use by others could still use good branch management. Consider the need to work on a new version while still maintaining the previous version, for instance -- and to backport security fixes.

Justin James
Justin James

I'm interested in knowing what you think of it. I'm not one of those, "oh, you didn't like it, you must be an idiot!" type of people... I fully recognize that different people have different needs and different tastes. TFS might be just what you need and want; for me, Mercurial is a much better source control system, and I need to get around to trying out the more integrated stacks with it like FogBugz. J.Ja

jmzamudio
jmzamudio

You are a Mercurial fanboy, I'm a TFS fanboy, but I will try Mercurial just to check it out and see how it goes (i cant really debate here if haven't use the product), i hope you really have cookies in the dark side.

Justin James
Justin James

... if you've been a reader for a while, you'll know that I very, very rarely descend into fanboyism... I'm a Mercurial fanboy and I admit it. There are only two or three products I've used that I like as much (OutSystems' Agile Platform, and the WP7 phone OS are the only two I can think of off hand, related to computers). I'm not prone to the fanboy mindset, so if a product causes me to have it, that says something I think. J.Ja

Justin James
Justin James

... when that's all you've used, or if you are coming from something like ClearCase or SourceSafe. When I started using TFS, my previous experiences had indeed been those two systems, and by comparison, TFS was an absolutely joy. For one thing, I wasn't waiting for it to demolish my data like SourceSafe, and ClearCase would often require a ton of jimmying to get things to work if you forgot a step along the way. I tried SVN, and while it was OK as a system, the Visual Studio plugins were wretched... in a week, I lost many hours to it. A few times it took me nearly 45 minutes of twiddling to get a simple, non-merging check-in to happen! And yes, TFS has great integration... if you need the full and complete stack, from check-ins to automated builds, testing, deployment to test servers, etc., it's a great package. You can stitch together similar pieces with other packages, but TFS is the only one (that I know of) that does it all in one unified package. But for basic source control management, it's a headache. Please, give Mercurial a try. It will take less than 15 minutes of downloads, setups, etc. (that's a nice change from TFS right there...). No SharePoint involved. :) Here's what, to me, works so much better about Mercurial: * Every check-in is a branch. This means that all of the stuff you normally branch for, like cutting a new version, doing some experimentation, etc., doesn't need to be thought about in advance. With TFS, if I'm in the middle of working and say, "gee, this should be a branch..." I have to go back to "the process" and sort it out. * In TFS, every branch is a full copy. In Mercurial, branches are differentials. This makes it a lot easier to combine two separate branches. For example, if I'm working on component A and you are working on B, we can bring them together much more easily. * In TFS, everyone is working off the same code, it's centralized. So if we want to cut a version, and I am working on two separate items, one that is ready to go into the new version and one that isn't, I need to be very delicate. With Mercurial, this is a cinch. I just merge the check-in with the finished change to the main server. * With Mercurial, everyone is, by default, working locally, so things don't pollute the shared branch. At the same time, it's very easy to get items into the main branch on point-by-point basis. * Creating projects in TFS is a hassle, and pollutes the system quickly. Creating them in Mercurial is a cinch. Look, I like TFS and it's a decent product, but the fact is, it's issues are actually highlighted by something you wrote: "if you have branches you don???t need what is broken is your process, not the tool." With TFS, teams have to spend a lot of time talking about process and thinking about it, to keep from tripping over themselves. With Mercurial, this is much less the case. Again, I encourage you to give it a try... say... 1 - 2 days, just do a checkout from TFS, copy the files, stick the repository on top of it, and when you're done, check your changes into TFS. That's a "no harm, no foul" test. I think that it will be a real eye opener for you. It certainly was for me. I liked TFS a lot until I tried Mercurial, now I still like it, and respect it, but not nearly as much as I used to. J.Ja

jmzamudio
jmzamudio

First you complain about is too complex to use for a single person, then you say that to do anything usefull you need branches, care to enlight me what usefull features are you loosing with a single branch when working solo? I have never using Mercurial, but in TFS I just right click a folder, choose "Create Branch", give it a path, work on it and when I'm done right click and choose "Merge", whats dificult about it?, I mean if you are working solo in a project thats all it takes. I've been using it for years too (since the release of TFS 2008 in 11/2007, and I'm the administrator btw), and while I understand that its not for everybody the integrations of all the tools it's incredible for us.

apotheon
apotheon

Maybe if you get your employers to hire me for a consult . . .

apotheon
apotheon

I'm sorry, I can't help myself. That's terrible -- and I'm still laughing.