I'm taking my first look at Jira.  It's only been a few minutes.   My first impression is that it looks powerful, intelligent.   The live system at Atlassian has zippy response too.  I want to explore it some more.

 

But... I got side-tracked reading the list of the most popular issues in Jira itself (see screenshot below) as determined by customer voting.  For me, as a tracker author, it's fun.  (Oh, BugTracker.NET doesn't have a voting feature.  Darn.)

 

I'm feeling Schadenfreude and Empathy at the same time, if that's possible.

 

Schadenfreude, because I'm competing with Jira.   Well, BugTracker.NET is free, so I'm not really competing.   But in my own head, in a fantasy-football sort of way, I'm competing, so I gloat seeing items in that list that BugTracker.NET *CAN* do like,  "Required: Project Group Administrator", and "Search/filter for 'empty' fields".

 

But Empathy, when I see a request like the 5th one, "Priorities, Resolutions, and Statuses per project / issue type."  That would be an extremely challenging change for me to do in BugTracker.NET.  Some folks have asked me for that kind of slicing and dicing.  I'm reluctant.   One big part of the challenge would be to preserve backwards compatibility. With enough logic, it can be done, but the resulting code would be so hard to read that it would put my brain at its limit.   I wouldn't have confidence that my logic would be reliable.  There's no way that I could add the complexity without making mistakes that would disrupt my users who trusted me enough to upgrade.

 

Another challenge would be how to package all that flexibility so that the web pages wouldn't be too scary for users.  How much configuration would a user have to do before they could enter their very first issue? One of the reasons people love BugTracker.NET is that it is easy. At what point would the configurability overwhelm the simplicity that people are drawn to?

 

I have this impression that Jira's customers are especially demanding.   Maybe, because Jira already *IS* so highly configurable, and because Jira responds to customer request for more configurability, it attracts customers who ARE ATTRACTED to configurability.  Jira gives them a lot, but they want MORE.   There's some sort of no-good-deed-goes-unpunished mechanism that is happening to the Jira developers.  As they add complexity, that just makes the OCD sufferers among their customers more demanding. It happens to me too. So, Empathy.

 

See the 10th item, "Sub-issues should be able to contain their own sub-issues".  Jira's customers demand that feature, and Jira will probably deliver it one day.  Contrast the Jira situation with how FogBugz deals with demands for ever more complexity from its customers. Somebody quotes Joel Spolsky of FogBugz doing a sales demo.  He was asked, "Can FogBugz support creating dependencies between bugs?" His flip, dismissive answer was, “Sure, just type ‘depends on case 123′.”   There probably will never be an N-tier web of issues in FogBugz.  The FogBugz approach to their customers is more, You-Aren't-Going-To-Need-It.  I'm not saying that's a bad thing either, because that's how they preserve simplicity.  

 

When I was putting together the page on issue tracking system comparisons I ran across instances where an evaluator had eliminated an issue tracker from consideration because it was too complex. Simplicity itself is a nice feature too.  No news there.