Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Fogbugz lost to Jira

movingfulcrum.com

Post reply on HN
Print view View original

231–240 of 251 posts

Re: Why Fogbugz lost to Jira

#231

Post by mwhuber »

keypusher wrote: post #225
mwhuber wrote: post #33

Earlier quoted context omitted.

We use vanilla Jira and I find it painful - over-reliance on modals, slow JS calls, etc.; I do enjoy Source Tree. As a PM, Pivotal Tracker (used in a previous life) is one of the best work-tools I've ever used.

Pivotal isn't really a bug tracker though, is it? It's more for tracking project tasks. On some projects, these might be similar things, but when you have a large QA team and customer support teams, I don't think it's going to cut it.

It just depends on the process you put around it. Our team wasn't huge - ~13 if you include QA - but effective use of labels and "task" state management made it great.

Re: Why Fogbugz lost to Jira

#232

Post by SonicSoul »

glass- wrote: post #79
outworlder wrote: post #3

Earlier quoted context omitted.

An interesting point from that, since everyone likes to bash Wasabi: > "If we hadn't done Wasabi, then we'd have had to rewrite all of FogBugz, and that would've killed the company. Wasabi also gave us stuff that developers are only now rediscovering, like code that executes on both client and server (e.g. via server-side/client-side React), that even gave us a development edge. I've written about this at length ( ht…

This blog post about Wasabi is worth a read (another perspective from someone who worked there): http://www.tedunangst.com/flak/post/technical-debt-and-tacki...

great post and it changed my perspective on what wasabi was. This part makes complete sense:

Working on FogBugz changed my perspective on technical debt. I used to believe, as I suspect many do, that it was strictly a bad thing. You took a shortcut because you’re lazy, and then it comes back later to bite you. Count how many times that Wikipedia article uses the word “lack”. As the originator of the term Ward Cunningham explains, that’s off the mark. Buying something with credit doesn’t automatically imply you’re not going to pay your bills.

Instead of thinking of technical debt as yesterday’s work that I failed to do, I think of it as tomorrow’s feature I can have today. You have to pay interest, but in the mean time you’re shipping a product, have a roof over your head, and are keeping the lights on. A much hipper programmer might say something like “you ain’t gonna need it.”

In one sense, Wasabi was a rather substantial payment on the debt we had accumulated. FogBugz was written in a now dead language. Building a compiler extended the life of the product, though of course now we had to pay for the compiler, too. So maybe it was more like a bridge loan, or refinancing. The financial wellbeing of Fog Creek at the time depended on FogBugz, so a total rewrite would have been a terribly risky investment. Even if it costs more in the long run, spreading those payments out over time gets you a lot of stability.

while I also enjoyed Coding Horrors: Has Joel Spolsky Jumped the Shark?[0], Jeff either missed this point or ignored it on purpose to support the shark-jump theory

[0] http://blog.codinghorror.com/has-joel-spolsky-jumped-the-sha...

Re: Why Fogbugz lost to Jira

#233

Post by Grue3 »

jeffmk wrote: post #130

Has anyone had experience with Redmine [1]? It's quite easy to use and extend via its plugin system, but I don't see many people who have encountered it in the wild. I think its horrendous out-of-the-box look-and-feel detract heavily from its appeal. Nowadays I'd probably lean toward Gitlab, which seems to offer much of the same but appears much more modern. [1] https://www.redmine.org/

Using it at my current job and used it before. It's shit. Hard to keep track of issues because of awful UI. Give me JIRA any day.

Re: Why Fogbugz lost to Jira

#234

Post by mikeryan »

philliphaydon wrote: post #169
manicdee wrote: post #57

Earlier quoted context omitted.

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

Jeez so many replies to jira hate with. Oh buts how you configure it. Oh its this. It's that. Stop apologising for a shitty product. If a user find it hard. It's failed. End of story.

If a user find it hard. It's failed. End of story.

Yet Jira is a wildly successful product.

Re: Why Fogbugz lost to Jira

#235

Post by wpietri »

keypusher wrote: post #222
wpietri wrote: post #128

Earlier quoted context omitted.

That is not my understanding of what most large companies do. Over and over I talk to people who have to deal with fixed dates and fixed scopes. The common outcomes seem to be: 1. Wait until the date is close. Redefine scope in a panic so that success can be declared. 2. Wait until the date has arrived or is past. Have rounds of tears and/or shouting; pick a new date and scope, often as illusory as the first. 3. When…

Indeed, there are many wrong ways to go about doing things. That doesn't mean there aren't also correct ways, and companies who do them that way. In many cases, big projects at large companies require a date. This is how you accomplish that goal.

Here we get to what I think of as the heart of the problem. Projects don't require dates. High-status humans in control-oriented systems sometimes choose to require dates as a means of feeling in control.

The outcomes I describe above aren't some strange, rare occurrence. They are the normal outcome for projects formed around arbitrary scope/date choices. But people keep doing it. Indeed, they often can't even conceive of alternatives. Why is why, as here, people speak of the choice as an intrinsic property of the project rather than a consciously made decision among a variety of approaches.

This isn't a human universal, by the way. All of this is an outgrowth of western 20th century business culture and management techniques. But it is so much the dominant culture now that alternatives are literally unthinkable for a lot of people.

Re: Why Fogbugz lost to Jira

#236

Post by wpietri »

nl wrote: post #221
wpietri wrote: post #128

Earlier quoted context omitted.

That is not my understanding of what most large companies do. Over and over I talk to people who have to deal with fixed dates and fixed scopes. The common outcomes seem to be: 1. Wait until the date is close. Redefine scope in a panic so that success can be declared. 2. Wait until the date has arrived or is past. Have rounds of tears and/or shouting; pick a new date and scope, often as illusory as the first. 3. When…

I've been in all these situations. The key is to over communicate. When I'm managing a project like that in a situation like that I send an email similar to this: As it currently stands our team will not make the deadline. In order to meet our priorities, I would like to redefine "feature A" to exclude "component Z". This means we will have to do manual work around X. The following alternatives are available: (A) cha…

I think it depends on the company. I've worked inside organizations where that be entirely unacceptable. The date and feature sets are both fixed in advance and are treated as immutable. Nobody would say what you said, but if they did, they'd be on their way out.

Re: Why Fogbugz lost to Jira

#237

Post by GedByrne »

solutionyogi wrote: post #29

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…

Not supporting custom fields was a deliberate decision: http://www.joelonsoftware.com/news/20020912.html

"But the dilemma for us is that many customers are evaluating bug tracking software and they consider the lack of custom fields to be a major weakness in our product.... But it's still rude of me to tell customers that we don't have that feature for their own good, even though it usually is, and we're losing some sales because of it."

Re: Why Fogbugz lost to Jira

#238

Post by jharger »

wpietri wrote: post #236
nl wrote: post #221

Earlier quoted context omitted.

I've been in all these situations. The key is to over communicate. When I'm managing a project like that in a situation like that I send an email similar to this: As it currently stands our team will not make the deadline. In order to meet our priorities, I would like to redefine "feature A" to exclude "component Z". This means we will have to do manual work around X. The following alternatives are available: (A) cha…

I think it depends on the company. I've worked inside organizations where that be entirely unacceptable. The date and feature sets are both fixed in advance and are treated as immutable. Nobody would say what you said, but if they did, they'd be on their way out.

Was it the organization or a specific manager who responded that way?

Re: Why Fogbugz lost to Jira

#239

Post by atesti »

atesti wrote: post #214

For me the main way in which FogBugz has "lost" is that they silently discontinued the "FogBugz for your Server" version. The plugin system was great and we have our own installation on our own systems (no cloud allowed). With the "performance upgrade" they seem to have forked FogBugz, thrown out all the plugins, Lucene search and redid the GUI. And stopped updates for the server version: http://help.fogcreek.com/fog…

Here is the FAQ which outlines that plugins and the old FogBugz for your server has been discontinued:

http://help.fogcreek.com/10706/future-of-for-your-server-faq

Very sad

Re: Why Fogbugz lost to Jira

#240

Post by brazzledazzle »

lugg wrote: post #185
brazzledazzle wrote: post #131

Earlier quoted context omitted.

You only have to enter two fields in your workflow and it feels clunky? This doesn't jive with my experience at all but perhaps you're on an old version or it's resource starved. Once you start beating up jira or confluence you have to start tweaking defaults and jvm settings to get the most out of it.

It's a managed account. The 2 fields workflow doesn't feel too clunky, but the interface certainly is, and the speed, oh dear lord, the speed. Its just sooo slow.

I assume managed account means it's hosted by someone else. Unless it's Atlassian themselves they're probably being cheap and giving it as little resources as possible and it not being on-prem probably contributes to the feeling of slowness.
Post reply on HN