7 ms·

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 howe

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 Probability Distribution chart and Burn Down Chart [2]. Anyone who has worked for big companies knows that these two are USELESS for them. They set a project delivery date and you just have to hit it. At my current company, we are going for SOC1 compliance. This forces an amazingly complicated issue workflow and they implemented it very easily in Jira. I am looking at FogBugz documentation on workflows [1], and I don't see how we could have implemented the same in FogBugz. I also feel that Jira has a better ecosystem for plugins and integrations then FogBugz. [1] http://help.fogcreek.com/7483/statuses-categories-and-workflows http://help.fogcreek.com/7483/statuses-categories-and-workfl... [2] http://www.fogcreek.com/fogbugz/features/project-management/ http://www.fogcreek.com/fogbugz/features/project-management/

omouse 11y ago
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 control is needed (your compliance case) but generally you don't need it.
- smackfu 11y ago
  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.
  - caf 11y ago
    I was at a job where we did that in the early 2000s.
- solutionyogi 11y ago
  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.
- simcop2387 11y ago
  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.
- DavidPlumpton 11y ago
  They used to say the Space Shuttle isn't ready to fly unless the weight of the paperwork is equal to the weight of the shuttle.
  - dodders 11y ago
    My first job was writing JCL decks on an IBM ESA/390. We had several shelves of manuals for the thing. And people read them.
- deleted 11y ago
  [deleted]
mpdehaan2 11y ago
I will agree that "intelligent" time tracking features in FogBuz ~4 years ago seemed relatively flaky and random. JIRA's benefits are likely in customization - which is a giant pain for managers in some ways, but it's nice that it can do it, but JIRA is supremely frustrating when editing dashboards. Every time somebody changed a component name, it would break all the underlying queries, etc. I think there's a huge market for someone to overtake JIRA because it's so unfriendly, and I was very happy for various projects that had a team scope small enough to use Trello, but with better searching and a few more (optional) controls on top or something. Since there's common DNA there, I think Trello could evolve to be that. I hope it can. (BTW, I'm also nostalgic a tiny tiny amount for the end-user usability of Trac.)
- herge 11y ago
  All bug trackers are literally crap. It's a really hard tool to write. The ones that make dealing with individual items/cases/tickets like Trello fall apart when you are dealing with hundred's of items. The ones that manage groups of items together efficiently (jira, maybe fogbugz) are a pain to do data entry in.
  - mark9white 11y ago
    Try TargetProcess ... Gets very little attention. But hits that sweet spot for me at least.
  - eterm 11y ago
    And then there are those which seem to manage collections and data entry but fall down completely when it comes to dashboards and data presentation. (see youtrack).
Meekro 11y ago
They set a project delivery date and you just have to hit it. Do you find that this really works out, in practice? Joel has argued[1] that the only schedule worth anything is the one set by the developers themselves. Management can set relative priorities (X is twice as important as Y), but trying to force a faster deadline on the developers is like trying to make your Linux box run faster by renice-ing every process to -20. Now, the problem with developer-set schedules is that they tend to underestimate how long things will take. Hence, FogBugz figures out how much each developer underestimates on average, and builds bell curves for the realistic completion time. [1] http://www.joelonsoftware.com/items/2007/10/26.html http://www.joelonsoftware.com/items/2007/10/26.html
- codeulike 11y ago
  Do you find that this really works out, in practice? No. Good luck persuading the management to try something else!
  - iwwr 11y ago
    There may be a niche for enlightened managers or startup funders to promote such a thinking. If successful it will lead to a clear competitive advantage.
    - retrogradeorbit 11y ago
      This is true. But there is no competitive advantage in going and broadcasting to all your competitors exactly how you achieved the advantage. So the development shops that succeed using this will keep it tight.
  - shoo 11y ago
    Rob Thomsett had an article titled "Estimation Games" published in American Programmer, 1996: > It is our belief that over the 30 plus years of commercial computing has developed a series of sophisticated political games that have become a replacement for estimation as a formal process. > More importantly, like all good games they are passed on from generation to generation by "children" I.T. people learning from "adult" managers who of course learnt the games from their adults when they were children and so on. Of course, none of the academic institutions [our preschools] prepare the new I.T. graduate for these games but rather, leave it to the cold reality of the work environment to teach graduates [the new children] that estimation techniques are only good for teaching in university. > The good news is that I.T. can estimate better. The bad news is that there are lifetimes of games and refining of games that have to be avoided to do this. There used to be a good copy of it easily visible on the web, today the best I can find for you is this PDF copy of the article: http://research.cs.queensu.ca/~ahmed/home/teaching/CISC322/F09/files/EstimatingGames.pdf http://research.cs.queensu.ca/~ahmed/home/teaching/CISC322/F... Previous HN discussion (~200 days ago): https://news.ycombinator.com/item?id=9182814 https://news.ycombinator.com/item?id=9182814 Also worth a read for a chuckle: http://www.dadhacker.com/blog/?p=2267 http://www.dadhacker.com/blog/?p=2267
GedByrne 11y ago
Not supporting custom fields was a deliberate decision: http://www.joelonsoftware.com/news/20020912.html 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."

omouse 11y ago

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 control is needed (your compliance case) but generally you don't need it.

smackfu 11y ago
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.
- caf 11y ago
  I was at a job where we did that in the early 2000s.
solutionyogi 11y ago
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.
simcop2387 11y ago
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.
DavidPlumpton 11y ago
They used to say the Space Shuttle isn't ready to fly unless the weight of the paperwork is equal to the weight of the shuttle.
- dodders 11y ago
  My first job was writing JCL decks on an IBM ESA/390. We had several shelves of manuals for the thing. And people read them.
deleted 11y ago
[deleted]

mpdehaan2 11y ago

I will agree that "intelligent" time tracking features in FogBuz ~4 years ago seemed relatively flaky and random. JIRA's benefits are likely in customization - which is a giant pain for managers in some ways, but it's nice that it can do it, but JIRA is supremely frustrating when editing dashboards. Every time somebody changed a component name, it would break all the underlying queries, etc. I think there's a huge market for someone to overtake JIRA because it's so unfriendly, and I was very happy for various projects that had a team scope small enough to use Trello, but with better searching and a few more (optional) controls on top or something. Since there's common DNA there, I think Trello could evolve to be that. I hope it can. (BTW, I'm also nostalgic a tiny tiny amount for the end-user usability of Trac.)

herge 11y ago
All bug trackers are literally crap. It's a really hard tool to write. The ones that make dealing with individual items/cases/tickets like Trello fall apart when you are dealing with hundred's of items. The ones that manage groups of items together efficiently (jira, maybe fogbugz) are a pain to do data entry in.
- mark9white 11y ago
  Try TargetProcess ... Gets very little attention. But hits that sweet spot for me at least.
- eterm 11y ago
  And then there are those which seem to manage collections and data entry but fall down completely when it comes to dashboards and data presentation. (see youtrack).

Meekro 11y ago

They set a project delivery date and you just have to hit it. Do you find that this really works out, in practice? Joel has argued[1] that the only schedule worth anything is the one set by the developers themselves. Management can set relative priorities (X is twice as important as Y), but trying to force a faster deadline on the developers is like trying to make your Linux box run faster by renice-ing every process to -20. Now, the problem with developer-set schedules is that they tend to underestimate how long things will take. Hence, FogBugz figures out how much each developer underestimates on average, and builds bell curves for the realistic completion time. [1] http://www.joelonsoftware.com/items/2007/10/26.html http://www.joelonsoftware.com/items/2007/10/26.html

codeulike 11y ago
Do you find that this really works out, in practice? No. Good luck persuading the management to try something else!
- iwwr 11y ago
  There may be a niche for enlightened managers or startup funders to promote such a thinking. If successful it will lead to a clear competitive advantage.
  - retrogradeorbit 11y ago
    This is true. But there is no competitive advantage in going and broadcasting to all your competitors exactly how you achieved the advantage. So the development shops that succeed using this will keep it tight.
- shoo 11y ago
  Rob Thomsett had an article titled "Estimation Games" published in American Programmer, 1996: > It is our belief that over the 30 plus years of commercial computing has developed a series of sophisticated political games that have become a replacement for estimation as a formal process. > More importantly, like all good games they are passed on from generation to generation by "children" I.T. people learning from "adult" managers who of course learnt the games from their adults when they were children and so on. Of course, none of the academic institutions [our preschools] prepare the new I.T. graduate for these games but rather, leave it to the cold reality of the work environment to teach graduates [the new children] that estimation techniques are only good for teaching in university. > The good news is that I.T. can estimate better. The bad news is that there are lifetimes of games and refining of games that have to be avoided to do this. There used to be a good copy of it easily visible on the web, today the best I can find for you is this PDF copy of the article: http://research.cs.queensu.ca/~ahmed/home/teaching/CISC322/F09/files/EstimatingGames.pdf http://research.cs.queensu.ca/~ahmed/home/teaching/CISC322/F... Previous HN discussion (~200 days ago): https://news.ycombinator.com/item?id=9182814 https://news.ycombinator.com/item?id=9182814 Also worth a read for a chuckle: http://www.dadhacker.com/blog/?p=2267 http://www.dadhacker.com/blog/?p=2267

GedByrne 11y ago

Not supporting custom fields was a deliberate decision: http://www.joelonsoftware.com/news/20020912.html 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."