Live data from Hacker News

Why Fogbugz lost to Jira

movingfulcrum.com

51–60 of 251 posts

Re: Why Fogbugz lost to Jira

#51
post #37

Having 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…

I am not suggesting that you don't need technology.

I am suggesting that FogBugz doesn't offer enough flexibility in their workflow definition to do the gymnastics required for SOC1 compliance. FogBugz is trying to follow best software development practices and as you noted, Jira is a dream-tool for a micro-manager.

Re: Why Fogbugz lost to Jira

#52
post #37

Having 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…

While I don't have any real data, for a good look at how it was done before things like Jira and FogBugz, I'd first look at IBM and the military. IBM used to do a lot of consulting for both documentation and process compliance though I don't know much of the details (mostly heard stories from my uncle who works for them). The military did it largely with strict discipline and documenting everything in triplicate if the media is any indication and even then they likely weren't perfect.

The technology layers enable a strict uncaring rule keeper to do the job at all times and enforce things even if they might not apply, it makes the task simpler but it's still some of the same idea, a single bottleneck exists to ensure compliance for something and it gets well documented.

Re: Why Fogbugz lost to Jira

#53
The one feature of Fogbugz that I really like (and the reason I use it) is evidence based scheduling: http://www.joelonsoftware.com/items/2007/10/26.html

It takes away a lot of pain associated with giving estimates, especially from a manager's point of view. Devs need to break their tasks down to subtasks of sufficient granularity, and estimate the number of hours/days it would take them to complete each of these subtasks. Fogbugz does everything else, and gives a nice probability distribution chart of completion date that you can share with the stakeholders.

Re: Why Fogbugz lost to Jira

#54
Couldn't disagree more on the integrated wiki point. Issue trackers with integrated documentation pages (wikis or otherwise) make it really straightforward to generate docs as a byproduct of working on tickets, or to resolve support requests by linking to the docs. Eventually you will want an external documentation tool, but Atlassian doesn't have one that's any good (Confluence is by far the worst wiki-like application I have ever used).

Re: Why Fogbugz lost to Jira

#55
post #25

Earlier quoted context omitted.

Does the opposite kind of user exist? Has anyone ever met a fanatical JIRA lover? In my experience there are only people that tolerate JIRA on one side of the spectrum and a bunch of people that hate JIRA on the other side.

I love JIRA and would absolutely advocate for using it over any other tracker. With just a little tweaking (30 minutes or so on a fresh install), I can have it perfectly configured to match my ideal workflow.

Have you considered the possibility that your cow-orkers hate it, and by extension, you?

Re: Why Fogbugz lost to Jira

#56
post #32

Seems 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…

I think having the process explicty shown visually is better than just a "In progress" column. That way everyone knows where every other task is.

In progress could mean anything from writing specs, ui design, dev or testing

Re: Why Fogbugz lost to Jira

#57

And yet, "Creating a JIRA task is like going to the fucking DMV." https://twitter.com/jesseherlitz/status/648557144845910016

Only if your installation is set up that way. Here's how I create a Jira ticket in my organisation: 1. Click "Create Issue", 2. type in a summary (the headline), 3. type in the detail, 3. Click "Create"

If you have more stuff to fill out, that's an issue with your local configuration. Blame your Jira master, not Jira or Atlassian :D

Re: Why Fogbugz lost to Jira

#58

Seems to me Atlassian "won" because they had a actual sales team not because of "technology".

Well, reading this it's pretty painfully obvious that Atlasssian knew how to market a product better than Fog Creek, at least at the time. So sure, I'd agree the outcome was probably mostly not due to technology, but marketing is important. (I mean marketing in the old-school sense of knowing the market you're selling in, in addition to advertising and publicity)

Re: Why Fogbugz lost to Jira

#59

A 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…

Issue tracking systems are very important, even tracking a handfull is a pain over email or some other non-standardized process.

The way to keep the system effective is regularly close issues that have had no updates for, say 30 days. If someone cares about it, it will be re-opened. If no one notices, well it can be closed.

Good issue tracking system is just as helpful for the coders as it is for QA, PM and the rest of the team. If it isn't, you need to discuss improving it rather then abandoning it all together.

Re: Why Fogbugz lost to Jira

#60
post #25

And yet, "Creating a JIRA task is like going to the fucking DMV." https://twitter.com/jesseherlitz/status/648557144845910016

Does the opposite kind of user exist? Has anyone ever met a fanatical JIRA lover? In my experience there are only people that tolerate JIRA on one side of the spectrum and a bunch of people that hate JIRA on the other side.

Issue trackers are like utilities, like electricity and water. If they're doing their job, they're invisible. You only notice them when they're broken.

As a result, all issue trackers have more detractors than promotors, with the vast majority of users being neutral.

Post reply on HN