I not heard good things about Jira's ease of use
Why Fogbugz lost to Jira
41–50 of 251 posts
Re: Why Fogbugz lost to Jira
#42My guess is that Fogbugz is a cash cow without much new development effort. The focus of FogCreek's founders is on StackExchange and Trello now.
Re: Why Fogbugz lost to Jira
#43>> While most of these plugins didn't offer much in terms of functionality, for the person making a decision, it definitely helped to tip the scales in Jira's favor. For me, this kinda encapsulates the problem with Jira. Jira is extremely impressive in the number of features, plugins, and customization opportunities it offers, and yet, I can't honestly say even half of the stuff is in any way helpful to me as a devel…
as always, a different half is helpful to any particular user. add all the users together and you're back with the full feature set.
Re: Why Fogbugz lost to Jira
#44Earlier quoted context omitted.
Asking around on IRC, it just seems like bitbucket doesn't bring Atlassian a lot of money. It seems that they just see it as marketing for their other offerings, so accordingly bitbucket does not get a lot development. I wish they improved their Mercurial support. I believe they have only one guy handling all of the Mercurial issues.
That makes sense. I'd guess the main reason people use Bitbucket over Github is "free private repos," with "we already use other Atlassian products" a close second.
The only reason I looked outside of GitHub was Bitbucket's free private repos.
Now, for our academic lab, we're working entirely with Bitbucket (for the UI), and repositoryhosting (for low-cost repo archival with many users).
In an academic setting, where private repos are created for each small collaborative project, then left idle but accessible, GitHub's per-private-repo pricing model is prohibitive.
Re: Why Fogbugz lost to Jira
#45A bit off topic, and I know I'm sounding like a condescending jerk here but I mean it: but why do people love bugs so much that they want to purchase an entire database program to track them? I mean, if you have more than 10 bugs that are highly important to keep track of, it seems to me that you have much larger problem than whether to purchase JIRA or FogBugz. I mean, either a bug is important to you so prioritize…
You've got more than 10 bugs. You just don't know it yet. But really, "bug tracker" is just a colloquial expression for the more accurate "issue tracker" which can definitely include things like improvements, new features, A/B tests you want to run, etc.
It is possible that their software isn't large enough to have 10 bugs... they could be implementing FizzBuzz.
Re: Why Fogbugz lost to Jira
#46I still can't believe they invented their own language... but #1 seems like it would have been enough.
I hate using JIRA, though, just like I hate using all Atlasssian products, so it would have been nice if FogBugz won.
Re: Why Fogbugz lost to Jira
#47I was working at a large British bank in 2005 when Jira started to get adoption by several teams. The approved bug tracking product was ClearCase ClearQuest. If you think the Jira GUI is ropey you should see ClearQuest. Absolute nightmare. By contrast Jira was free to get started, and much nicer than corporate approved incumbents. They called it land and expand!
Re: Why Fogbugz lost to Jira
#48A bit off topic, and I know I'm sounding like a condescending jerk here but I mean it: but why do people love bugs so much that they want to purchase an entire database program to track them? I mean, if you have more than 10 bugs that are highly important to keep track of, it seems to me that you have much larger problem than whether to purchase JIRA or FogBugz. I mean, either a bug is important to you so prioritize…
I've heard this POV before, and I'm somewhat sympathetic to it. Sometimes, it's better just to fix things immediately rather than devote a whole process toward fixing them later.
The problem is that the flip side of fixing bugs immediately is interruptions. If, every time you discover a bug, you have to fix it or forget about it, it means that every time a new bug comes up you're going to have a PM interrupting an engineer. Eventually your engineer isn't going to be able to get any work done, and productivity grinds to a halt. It also puts a big damper on doing any large features, speculative features, hard features, or basically anything that requires sustained concentration for long periods of time.
Indeed, as a tech lead, one of the signals I use for when it's time to introduce a formal process and bugtracker is when the engineers on my team start complaining that they can't get any work done because they're being pulled in too many directions at once. If it's not a problem, then there's no need to slow yourself down with process to fix it. But if it is a problem, it's good to have a strategy that captures all the work that needs to be done and lets everyone coordinate who & when they'll do it.
Re: Why Fogbugz lost to Jira
#49Seems to me Atlassian "won" because they had a actual sales team not because of "technology".
They won because they allow managers to be in control and authoritarians. I've seen more than 2 managers who take over JIRA and lock down permissions and create custom workflows and all of them insist on having swim lanes and 5+ columns. So to move one little ticket across the board took 4+ drags. If you have a heavy-weight process where people are actually signing off on things, then yes it makes sense. But otherwis…
This was my experience, with Redmine instead of Fogbugz.
Re: Why Fogbugz lost to Jira
#50Having mainly done line of business applications my entire life, I have a slightly different take. Jira won because it was not opinionated. You can use it however you want. FogBugz had the philosophy to make bug entry super easy above anything else. Jira will let a manager define new custom fields and make them all compulsory. It perfectly fits how manager at big companies think. FogBugz provides Completion Date Prob…
I don't see how we could have implemented the same in FogBugz. How would you implement the compliance without technology in place? I'm being serious, how do you think compliance happened in the days of 486s, TRS-80s, punchcards or no computers at all? There isn't always a technical solution to a social problem, and JIRA's customizations are a micromanagers dreams. I'm sure there are good cases where that level of con…
Reminds me of the time we cleaned out a back storage room at an old job, and there were binders full of mainframe PL/I source code from the early 80's that had gone through paper code reviews, with the reviewers signature on every page.