Why Fogbugz lost to Jira
101–110 of 251 posts
Re: Why Fogbugz lost to Jira
#102I mean logically, if they've already given you the money and there isn't any way they can take over governance of the company, then the only leverage I can think of is signaling in future rounds. And if you weren't even going to raise one VC round, then at that point you may as well raise exactly one and then signaling is irrelevant. Yes you've diluted yourself 20% and now you've got a board member that wants you to grow fast, but so do you. Of course, I'm assuming here that you failed to raise on Kickstarter, and you aren't making enough $ to hire people to do development/testing/security/evangelism/PR/marketing/operations/etc. anytime soon. Why waste years of your life when you can hand the project off eventually to a community you've built, and move on? If you want to retain control over the project forever, can always be BDFL of the community, at least until some better-funded company forks it. I just really want to understand, what is the reason that guys like DHH say VC can control you after you take their money?
Re: Why Fogbugz lost to Jira
#103Earlier quoted context omitted.
Whoever designed JIRA's psuedo-markdown text format deserves a special place in hell.
Atlassian products tend to make me SO mad in this way. Confluence, can I just use markdown? No! Forget that I used it in so many other places. Oh but wait, someone may have built an importer... try to get that installed.
Re: Why Fogbugz lost to Jira
#104Yet FogBugz still feels way easier to use. Every time I'm in an Atlassian product, mainly Stash and JIRA, the UI sucks. I use them several times a week and still get lost. Maybe I'm dumb, but I don't seem to have this problem on other systems. But hey, at least JIRA isn't the craptastic laggy pos that is Podio. Certainly right that I've never seen FogBugz outside of myself or customers. Also, I think the name must hu…
I dunno, I had the opposite impression. I worked at a company from 2005-2007 that was evaluating FogBugz as a bugtracker, and found that (at least on Linux, which we were using) it was very unpolished. At the same time, some of our dependencies used Jira for their public issue tracker, and I recall looking at it and thinking it was the only bugtracker I'd actually like to use. Nowadays I'd probably just use GitHub Is…
Company I work at was founded in 2007 and we used trac up until around 2009 I think, then we switched to jira.
I am a big fan of jira. It's definitely more complicated than a simple bug tracker like bitbucket or github issues, but it is waaaaay more powerful than those.
Re: Why Fogbugz lost to Jira
#105Earlier quoted context omitted.
The relevant XKCD: https://xkcd.com/277/
Every JIRA product has it's own special markup. I can never remember how to write code into comments or titles. It literally changes from product to product and yet all of the products orchestrate together so that if you do happen to use Stash, JIRA, Wiki, etc all together, then you encounter as many different markup languages as there are Atlassian products. It really is hellish. I hope there's some good reason why…
Re: Why Fogbugz lost to Jira
#106Re: Why Fogbugz lost to Jira
#107Earlier quoted context omitted.
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…
Do you find that this really works out, in practice? No. Good luck persuading the management to try something else!
Re: Why Fogbugz lost to Jira
#108Earlier quoted context omitted.
You have a point, I guess I'm more flabbergasted by the particular language they chose to invent. Also, Fog Creek ain't exactly Ericsson or Sun.
Fog Creek probably had more resource than Yukihiro Matsumoto, Larry Wall, and Guido van Rossum did.
Re: Why Fogbugz lost to Jira
#109Having 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…
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…
beginning with Salesforce.com downwards you have vendors releasing on a fixed schedule.
your valve is scope, but even that is fairly fixed as customers drive what needs to get released when (not "stupid" managers).
Re: Why Fogbugz lost to Jira
#110Having 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…
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…
> Do you find that this really works out, in practice?
Of course it works. You just redefine the project (or parts of the project) as you go, shrinking (or occasionally growing) the scope.
There's nothing wrong with a fixed delivery date, provided you can adjust scope and/or resources (to some extent) to compensate.