JIRA, Pivotal Tracker, and Playnice.ly for issue tracking

-

I've used each of these tools on at least one project now (JIRA for quite a few) and thought I would share my observations about when each one would be most appropriate.

Pivotal Tracker

Pivotal Tracker is only offered as a cloud based or hosted solution, but has a pretty impressive list of customers. On the upside, they've fully embraced the cloud concept and offer a well documented set of RESTful APIs to integrate with third party systems. You can connect issues to SCM commits using post commit hooks from svn or git (or anything with a little effort)

I find the pivotal tracker User Interface be a bit confusing, but pretty useable out of the box and geared toward agile methods. Another big plus is that they can auto-estimate your actual velocity and burndown which helps you get your arms around your real velocity. In addition, they have some out of the box reporting.

playnice.ly

playnice.ly is also a hosted solution, but of the three has taken an more interesting approach to bug tracking. They've jumped on the gamification bandwagon and have tried to craft an experience that is actually enjoyable instead your typical cold-war soviet style user interaction that most bug/issue tracking systems seem to espouse. While innovative, they are missing some features and are decidedly still in the Minimun Viable Product stage.

You can integrate with git via post-commit hooks, but third party integration doesn't exist is still in beta and frankly the documentation was somewhat difficult to find (hint -- the link is in the footer). I can appreciate the idea of keeping things simple and this product will certainly work well for a small agile team or an independent who's just keeping track of things for himself. It's hard to say how this would scale to a larger team or very complex project as it is deliberately bare bones and I suspect this could work against you on a largish project or team.

JIRA

Last, but certainly not least, is Jira from Atlassian. I'd consider this the 800lb gorilla of bug/issue tracking and I've used it for years on multiple projects in a variety of teams and workflows. Frankly, you can do anything you want with this product... They can host it, or you can run it internally with a slew of different databases. It integrates with just about everything, and it has a plugin system that folks have used to build a vast array of plugins to help do just about anything you want.

The default user experience seems is horrendous and to match the impedence between what an agile/small team might need and the default JIRA config you're going to waste a lot of time either fetching plugins or configuring things to work how you want. JIRA's biggest strength is also it's biggest weakness and it would be difficult for me to recommend JIRA for smaller teams or startups as it's enormity imposes to some serious overhead --- either you eat the time trying to figure out the default UI or you eat the overhead of configuring it to be less complicated...

Here are the users I think would be a good fit for the tools:

  • A small team who just doesn't want to lose track of bugs or tasks, and has an interest in keeping an informal and deliberately fun culture - playnice.ly
  • A similarly small team, but one that finds a need for stronger organization and reporting options and/or if you think the idea of bug tracking being fun is somehow off putting - pivotal tracker
  • A large team or large organization who has thousands or hundreds of thousands of issues to track and will end up with a full time person or more to help manage track them. Additionally, if you need to host in-house, JIRA is the way to go

Comments

Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u
Read more