Why Fogbugz lost to Jira

http://movingfulcrum.com/why-fogbugz-lost-to-jira/

by pdeva1 • 11 years ago

312 241 11 years ago

movingfulcrum.com

JimDabell• 11 years ago

There's an interesting discussion happening on Reddit involving ex-employees of both companies:

https://www.reddit.com/r/programming/comments/3n2sc1/why_fog...

outworlder2• 11 years ago

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 (https://news.ycombinator.com/item?id=9779133) and won't revisit it, but while I think that Wasabi targeting .NET may have been a mistake, Wasabi itself was not a mistake."

sixothree4• 11 years ago

Hanselminutes podcast recently had an interview with Jacob Krall about the history of wasabi. I found it quite interesting.

http://hanselminutes.com/493/killing-off-wasabi-a-20yr-old-v...

glass-• 11 years ago

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...

zem2• 11 years ago

i thought wasabi was an excellent idea when i first read spolsky's post about it, and nothing i've heard since has changed my mind. these days, when i see it blamed for any of fogcreek's problems, i simply see it as a sign that the commenter is unfamiliar with the issues involved.

derefr2• 11 years ago

What I always fail to understand about Wasabi: why did they keep the code in the source language and compile to CLR object code, instead of running the same parser with a different codegen target, to transform the PHP wholesale into valid C# once, and then overwrite the codebase with that?

olavk• 11 years ago

They could have achieved the same (same code on client and server) if they had just written in JavaScript/JScript though. I bet JavaScript is also easier to translate to PHP and C# than VBScript. They also claim that Wasabi made it possible for them to add closures to VBScript. Cool, but again, using JavaScript from the beginning would have been a lot easier.

scott_s• 11 years ago

Very interesting. More insightful than the submitted piece, as the participants have inside knowledge and understanding of what went on.

curiousjorge• 11 years ago

I think the last bit about what didn't matter has a huge take away home value. It's ironic that so much crap we read today drives home these two things that we focus so much on:

1. Content Marketing

2. Sales Team

grossvogel3• 11 years ago

Joel on Software has 6 posts over the last 3 years. I'm not sure how long Jira has been winning (whatever that means), but it doesn't seem fair to say that Content Marketing doesn't work when the blog in question isn't actively updated.

benologist• 11 years ago

They're actively marketing their blog on HN -

https://news.ycombinator.com/from?site=fogcreek.com

gmarx• 11 years ago

I would argue that FogCreek's early success was the result of Joel's blog. Around that time he had said most of what he had to say and posting frequency declined. I haven't looked at his site more than a couple times in the past 10 years. So I think it did matter tremendously and momentum declined after that factor was removed

ohitsdom• 11 years ago

Fogcreek invented their own language. This meant they couldn't use all of the ecosystem and amazing tooling around Java

Java? I believe that should be .NET.

afsina3• 11 years ago

Op means unlike Atlassian, which is mostly a java shop.

sixothree4• 11 years ago

Also, I don't think .NET existed or was very mature when they created wasabi.

MichaelGG• 11 years ago

Yet 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 hurt them. It feels dumb bringing up "FogBugz yeah with a z". As silly as a reason that is, I think it carries some weight.

Content marketing may have helped them with SEO, no? Not that it SEO alone would close large enterprise deals.

Oh and the plugins on FogBugz did suck. I remember setting up a hosted account, and wanted to plugin to Github. Support sorta mentioned being able to custom hack something up, but IIRC, didn't actually give us any simple way to achieve it. (This was several years ago so perhaps I'm mis-remembering.)

rabid_fish• 11 years ago

I've used both, and I can only imagine your complaints about JIRA's UI are due to how it's been configured for your use.

The out of the box user experience is the best I've seen for a web application. A robust yet easy to use 'search' feature is at the heart of many things, like the scrum and kanban boards, as well as widgets that can be put on your own personalize dashboard. You get a nice visual designer for setting up workflows, and you can easily create new fields for issue types and have workflow depend on those fields.

I also find Stash to be well thought out and easy to use if your use-case is a pull-request workflow tied to JIRA. Sometimes it's not intuitive how to navigate around if you're just trying to view source, but that's not the selling point. If you're trying to navigate source history, use your local source control client, that's what it's built for.

outworlder2• 11 years ago

I've used both, and I can only imagine your complaints about JIRA's UI are due to how it's been configured for your use.

Exactly. There are some companies that go so overboard with Jira customizations that a single "create new issue" requires hitting page down three times to get to the end. And they arrive at that by adding a field here for the QA team, a field there for the Sales team...

In the end, you get a monster. New users will be exposed to that monster, not the vanilla Jira installation.

Domenic_S• 11 years ago

Whoever designed JIRA's psuedo-markdown text format deserves a special place in hell.

nostrademons2• 11 years ago

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 Issues - looking at Jira now it feels incredibly dated, but back then its only serious competitor was Trac. (Where is Trac, now, anyway? I haven't met someone who uses it in a while, but when I was founding my first startup in 2008 it was considered best-of-breed.)

fletchowns• 11 years ago

Trac is still around, Django still uses it. I thought rtorrent was using it too but a google search seems to indicate they migrate to github.

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.

1wd2• 11 years ago

Trac is still around. Trac 1.2 is planned this year. There are many users [1] e.g. jQuery, WebKit, WordPress, GHC, FFmpeg, ...

[1] http://trac.edgewall.org/wiki/TracUsers

omouse4• 11 years ago

I've overheard devs and marketing people talk about JIRA while walking down the street. It's really messed up.

sixothree4• 11 years ago

We use JIRA and I'm really disappointed with the user interface.

One of the simplest examples I can give is the inconsistent dropdown list. For most (but not all) dropdowns it lists all of the items except the one you currently have selected. This is a departure from every other system I have ever used and find it annoying.

stephen_g3• 11 years ago

The Jira and Stash (now Bitbucket Server) UI has come a long way in the last little while.

I think I have our company's Jira set up quite nicely, and really the only things that annoy me are the dropdowns (why isn't the selected item shown? Super confusing...) and not switching to Markdown for comment formatting.

amyjess2• 11 years ago

Yes, I've never liked anything about JIRA's UI.

I much prefer the UI used in Trac and its clones (e.g. Redmine), which is simple and straightforward.

stephen_g3• 11 years ago

That's interesting - I wonder if it's just because I've used JIRA so much and I'm more familiar with it but I find Redmine's interface super frustrating to use and it just feels unpolished.

spronkey• 11 years ago

Came here to say this (about the name). What corporate pointy eared would buy a product called FogBugz over one called JIRA? I mean really. No contest right there.

afsina3• 11 years ago

Also Atlassian products are multi platform. Whereas fogbugz is windows only for the server side. That is a deal breaker for many.Additionally unlike Fogbugz Atlassian products are DB agnostic.

julianz2• 11 years ago

Huh? We've been running Fogbugz on a Debian server with a MySQL database for years and years. Fog Creek may encourage Windows now but it still runs on Linux just fine.

afsina3• 11 years ago

They are no longer selling Linux versions. Also only MySQL and mssql are supported. MySQL is not recommended. http://help.fogcreek.com/7389/fogbugz-system-requirements

mariusmg• 11 years ago

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

SandersAK• 11 years ago

People really seem to downplay this, but Atlassian's partner network of integrators and consultants is actually really powerful.

anthonys• 11 years ago

Atlassian make a big point of saying they don't have a sales team[1] so I am not sure where this is coming from?

[1] https://www.atlassian.com/licensing/purchase-licensing

GFK_of_xmaspast• 11 years ago

From sour grapes?

brazzledazzle3• 11 years ago

Their sales team is their partner network. VARs.

thedufer2• 11 years ago

Atlassian could just as well title all of their engineers as "developers" and claim not to have an engineering team; the claim they're making is only true in a very narrow and ultimately meaningless sense.

They pay people to convince other companies to buy their product. The claim of "no sales people" stems from the fact that they only talk to people who contact them, rather than cold-calling.

This is, interestingly, also what the sales team at my company does. They are pretty sure they're doing sales, though, so we call them that.

omouse4• 11 years ago

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 otherwise it just irritates everyone.

They won because they appealed to the true buyer in the office; the CTO or VP of engineering, but they really appeal to the control-freak and micro-manager.

When I used Fogbugz in one office, it was the devs that pushed for its use and the project managers and other execs weren't able to screw it up; there was no obvious way of creating custom workflows or locking things down too much. Fogbugz let us get work done. JIRA in the hands of a micromanager makes me want to chew glass.

djur2• 11 years ago

This was my experience, with Redmine instead of Fogbugz.

UK-AL2• 11 years ago

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

flarg• 11 years ago

I had the same experience - pushing a client to use FogBugz because I knew it was not over-configurable so there wasn't much chance of the management screwing it up. I also found the estimation functionality quite wonderful. Worked well.

vailripper2• 11 years ago

We were on Fogbugz for many years, but eventually left to Jira because the Agile workflow is absolutely horrid.

Micromanagers can screw anything up - you can invent some pretty insane workflows using the FogBugz workflow tool, if you want to :)

keypusher3• 11 years ago

If management is that messed up, it really doesn't matter what bug tracker you use. Jira is more flexible, and threfore your bad managers can bend it to their will more easily. The solution to the problem is to find new managers.

draw_down3• 11 years ago

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)

camkego• 11 years ago

Doesn't Atlassian claim not have a sales team?

mrweasel• 11 years ago

Jira certainly is more popular, but I never viewed the two products as being in direct competition. I don't know about the inner working and finances of Fogcreek, but given that Fogbugz is still around they've may have lost anything.

Pricing would certainly be a knob Fogcreek could tweak, if they believed that they where losing to Jira in some shape or form. Given that they haven't lowered prices or expanded their free tier sales of Fogbugz could be on the precise path that Fogcreek want for the product. Maybe their selling extremely well in a marked that most HN readers just aren't in contact with. A marked that doesn't mind the added cost.

It's different approaches to sales, make a little money from a large pool of customers, or sell a more expensive product/service to a smaller market. Both strategies are completely valid, but due to Facebook, Twitter, Instagram, Uber and whatnot many will falsely assume that more customer is always better.

yaur• 11 years ago

A big thing with the pricing... If I'm an individual contributor and want a bug tracker, I can drop 10 bucks on a JIRA license (out of pocket) or convince someone from management that I need it and that they need to pay for it.

command_tab• 11 years ago

And yet, "Creating a JIRA task is like going to the fucking DMV."

https://twitter.com/jesseherlitz/status/648557144845910016

shill• 11 years ago

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.

morgante2• 11 years ago

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.

dfabulich• 11 years ago

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.

michaelt• 11 years ago

Even if you have the world's greatest system to queue for a scarce resource, you're not going to make people happy to queue :)

deckard1• 11 years ago

I'm far from loving any issue tracker.

That said, I've used RT (holy shit no), Pivotal Tracker (drinks too heavily from the dynamic DOM/JS koolaid, sucking up all RAM and CPU in the known universe), and JIRA. I'd take JIRA over the others.

philliphaydon4• 11 years ago

Never met anyone who likes it. Except the replies to this blog post.

manicdee• 11 years ago

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

lugg3• 11 years ago

I'm still going to blame Jira/Atlassian for making that workflow possible.

My work flow is exactly the same as yours, yet it still feels clunky, and is quite correctly, a total dog.

Much like, you know, going to the DMV.

philliphaydon4• 11 years ago

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.

mixmastamyk2• 11 years ago

On the other hand, I wish bitbucket were more popular compared to github. It doesn't seem like they invest much into bitbucket, as some silly issues have persisted for years. Have they given up?

jordigh2• 11 years ago

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.

grossvogel3• 11 years ago

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.

rajksarkar• 11 years ago

Nor true - we have been investing quite a lot on Bitbucket. Check out our most recent blog post: http://blog.bitbucket.org/2015/09/22/1-in-3-fortune-500-comp...

jordigh2• 11 years ago

You're letting Mercurial die, though.

And for all that investing, you are not fixing the bugs that annoy people the most. You let them languish for years:

https://bitbucket.org/site/master/issues/11813/allow-annotat...

https://bitbucket.org/site/master/issues/5008

https://bitbucket.org/site/master/issues/11864/ignore-whites...

mixmastamyk2• 11 years ago

New features are good, but so is fixing existing ones.

Many of the problems I had were trying to get readme.rst to work on bitbucket, readthedocs, and pypi. You all use different syntax to markup syntax highlighting! Even though you all use python! To my knowledge that hasn't been fixed, but not entirely sure because I gave up on it years ago.

Here's an important one for hg:

https://bitbucket.org/site/master/issues/6705/cant-create-pu...

fideloper• 11 years ago

Who is Prashant Deva and should I care about their opinion?

Did Fogbugz actually lose? Do they even have the same market (enterprise vs smaller)? Perhaps they just fine operating at a smaller volume.

Isn't the product being "too basic" a sign of focus? Perhaps the author needs/wants more features, but that can't be generalized for all of Fogbugz's audience.

I've heard just as many owners say "I don't want as many features as competitor X".

That all being said, there are some good things in there - perhaps Fogbugz could look into a partner ecosystem. Making your own language is probably a bad long-run choice.

However I get the feeling this is comparing apples to oranges.

skrebbel3• 11 years ago

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 fixing it, or it isn't important to you so you can just ignore it and see if it surfaces again.

Every single team I've seen that used a bug tracker ended up with hundreds of issues, status of 90% of which was unknown, maybe already fixed, maybe not relevant anymore because the entire component got overhauled the other day by Joe. What's the use of this stuff?

I got this from a blog post (by Ron Jeffries I believe, but I forgot), but basically his idea was that the moment you turn something that you don't want to have into a formalized process, people tend to bias towards getting more of it. If you are forced to choose between fixing a bug or forgetting about it, you're urged to fix it fast. If you can just "file the bug and go on with your work", the bug stays.

peterdkovacs• 11 years ago

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.

nobleach2• 11 years ago

It is possible that their software isn't large enough to have 10 bugs... they could be implementing FizzBuzz.

nostrademons2• 11 years ago

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.

ParadigmBlender• 11 years ago

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.

solutionyogi3• 11 years ago

What's your development experience? I am guessing that you haven't worked on line of business applications for big companies which takes years to develop.

I think it's a mistake to think that Jira and FogBugz are only used for tracking 'bugs'. They are obviously used for that but everyone I know uses them to track everything related to their software. Track features/support questions/infrastructure changes etc.

To give you an example, I am part of 50+ developer team implementing straight through processing for a large hedge fund. This involves developing variety of systems which are highly dependent on each other. Jira tells me that I have 120 items which I need to implement by this year end. Mind you, this is just one system. There are at least 10 more systems like that. I can confidently say that there at least 1000 items in our overall list which we need to work on. You absolutely need a tool like FogBugz or Jira to track them properly.

UK-AL2• 11 years ago

Theres not really "bug trackers", there issue trackers. All the micro tasks are created, organised and tracked though to completion. Often visually represented on a kanban board.

StillBored• 11 years ago

Which is a nice abstraction, but really fails with a little reflection. Bugs, shouldn't really have long lifecycles, dependency chains, target dates, etc... Features need these things but don't have wontfix, notabug, multiple branch targets, and discussions about reproduction. Which is why i always like running two different processes and joining the results at release mgmt/source tree level.

jo909• 11 years ago

In the end its just project management. I want to keep track of the things that still need to be worked on, so I don't forget them. I can delegate work, others can delegate work to me, work that requires other work or sub-steps can be passed around multiple people. The work can be described in detail, more input can be gathered, actions that were taken logged for future reference.

All of that can be achived in many many different ways of course, but software based ticket systems can work quite well in my opinion.

dustingetz• 11 years ago

That's a really interesting idea. As a data point, lets look at a healthy, modern, high quality project, what does it use the issue tracker for?

https://github.com/facebook/react/issues

They are using the issue tracker for all sorts of things, and it clearly has value.

krupan• 11 years ago

Turns out Linus isn't too fond of bug trackers either:

http://yarchive.net/comp/linux/bug_tracking.html

and the kernel seems to be doing pretty well.

solutionyogi3• 11 years ago

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-workfl...

[2] http://www.fogcreek.com/fogbugz/features/project-management/

omouse4• 11 years 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• 11 years 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.

solutionyogi3• 11 years 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• 11 years 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• 11 years 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.

mpdehaan2• 11 years 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• 11 years 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.

Meekro• 11 years 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

codeulike• 11 years ago

Do you find that this really works out, in practice?

No. Good luck persuading the management to try something else!

mtdewcmu• 11 years ago

Managers are the ones that buy this stuff, not developers.

pinaceae• 11 years ago

absolutely in enterprise SaaS.

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).

nl2• 11 years ago

> They set a project delivery date and you just have to hit it.
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.

mmatants• 11 years ago

Here's the issue, though - no matter how violently we may agree on the downsides of traditional project management, opinionated tools are just ahead of their time. The market is not at all ready to agree on what software workflow should look like. It just takes time for good techniques to propagate - this is such a young industry...

So until there is stable consensus among everyone up to even late adopters about how software work should be managed, any opinion built into the tool will end up being an obstacle for users who are still yet to learn agility the hard way.

The real value of an opinionated tool is the opinion itself. And that is something that has to be instilled first. Build a knowledge-base, a following, a community, then make the tool a companion piece.

overgard• 11 years ago

Kinda depends on if it's more important to be on time vs complete. Sometimes hitting a window of time is more important than getting the feature done perfectly, like for an industry event that could build buzz, or a specific holiday season where being late means a lot of lost sales. The worst deadlines are fixed ones for no point, though.

rukuu001• 11 years ago

Do you find that this really works out, in practice?

We often worked for clients that had media advertising booked and paid for. The product had to be ready.

So you make it work. Reduce scope, phase the releases, whatever it takes.

GedByrne• 11 years ago

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."

eikenberry• 11 years ago

This meant they couldn't use all of the ecosystem and amazing tooling around Java [...]

Does anyone else get the same confused feeling whenever they read things like this? Every experience I've had with the Java/JVM ecosystem has been anything but amazing to the point where I now avoid it like the plague. I can't believe I'm that much different than everyone else, but I see this often enough that it makes me wonder.

ZeroBugBounce• 11 years ago

Well, I can see it compared to writing and maintaining your own language + all associated tools.

I feel like Java is a "choose your own adventure" type thing. You can opt out of a lot of the bad, in my limited experience.

mindcrime• 11 years ago

Every experience I've had with the Java/JVM ecosystem has been anything but amazing to the point where I now avoid it like the plague.

Nope, just the opposite here. The JVM ecosystem is hands-down my preferred environment for building / deploying pretty much anything.

"Different strokes for different folks" and all that...

vacri5• 11 years ago

In the context of the article, java is not being compared against the pool of all available languages, but specifically against the in-house language Wasabi.

robotnoises• 11 years ago

> 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 developer.

zem2• 11 years ago

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.

Grazester• 11 years ago

I not heard good things about Jira's ease of use

mostlystatic• 11 years ago

My 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.

draw_down3• 11 years ago

I 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.

protomyth3• 11 years ago

Ericsson and Sun invented their own languages. If your a tool company, treating language as off-limits seems limiting.

draw_down3• 11 years ago

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.

osullivj• 11 years ago

I 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!

chaitanya• 11 years ago

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.

djur2• 11 years ago

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).

vailripper2• 11 years ago

Really? Have you tried using the Fogbugz wiki? I will take Confluence any day over that slow bloated POS.

alexwebb2• 11 years ago

Slightly off topic here but since everyone's chiming in about their experiences with bug trackers, I figure somebody might find it useful.

I did a pretty intensive search involving trials of a couple dozen trackers about two years ago when we decided to ditch Jira due to some serious performance and UI issues. I tested pretty much every serious contender on the market.

I ended up going with YouTrack and it's been pretty fantastic. One of those by-developers, for-developers things with a lot of functionality out of the box and a decent API for more advanced stuff, and most importantly it has very good performance and a sane UI. It does what it's supposed to do and then gets out of the way, which is exactly what I wanted. I recommend taking it for a spin if you're looking for something along those lines.

protomyth3• 11 years ago

Wasbi had nothing to do with it. JIRA caters to micro-managing mangers and FogBugz didn't. That is the simple lesson in enterprise. Trying to give a technical explanation isn't really telling the story.

PretzelFisch• 11 years ago

I would like he to define lost. Fogbugz is still around and profitable.

I have always seen Fogbugz as a support tool first, bug tracking kindof it's what they built for Fogcreek's process(for Copilot support and development). If you did everything like them it probably was a great fit. Jira on the other hand I have always seen as bug tracker.

baus2• 11 years ago

It could be argued that Trello will eventually be larger than either of these products, so I don't think the story has been completely told. I've used Jira as a manager in both a large and a small installation and hated it both times. It feels like 90s bug tracking system with huge forms and intractable workflows.

With that said, Spolsky (although I think a lot of his writing is fantastic) rarely addresses his mistakes.

__david__• 11 years ago

Trello doesn't really seem like a bug tracker. I haven't used it though—maybe I'm just missing something?

joncooper• 11 years ago

Agreed. I kind of don't get Trello. Always thought of it as kind of a lightweight "stack of cards" analogue best used for simple high-level planning along the lines of a Kanban board. Is that how people use it?

meshko2• 11 years ago

Never used Fogz, but Atlassian products are so astonishingly bad that it is hard to find anything about them inspiring.

meshko2• 11 years ago

I think the fact that my useless inflammatory comment didn't get immediately downvoted to hell is proof that I'm right!

emmelaich• 11 years ago

"bad" by itself doesn't mean much; the important thing is the relative goodness.

What were open source projects going to us instead? RequestTracker? Scarab? Bugzilla?

All of those were much worse than JIRA for development.

RT is fine for helpdesks but ugly as hell and no integration with SCMs.

Scarab never got to a satisfactory level of maturity.

Bugzilla? Just say no.

I've been a JIRA admin for 5 years now, and we seriously considered Fogbugz as well. I've never regretted our decision even though we've had plenty of issues() with JIRA.

free pun included.

zkhalique• 11 years ago

I have a question about raising VC money earlier. If you want to grow fast and push some free platform out to change the world, what is main danger in raising VC? I'm talking about the VCs these days who invest in companies that make open source like NGiNX, MySQL etc. And you need resources to grow, if you want to beat competitor platforms.

I 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?

wpietri6• 11 years ago

Once you take money from investors, you have both a legal and a moral responsibility to them.

It's important to remember that selling equity is really selling something, just like selling a product. You can't sell something, take somebody's money, and then just not deliver. What you are selling to investors, generally, is return on investment.

The real problem comes in because founders and VCs have different understandings of "grow fast". There will come choices that have different levels of risk. VCs always want you to take the high-risk, high-reward path, because they have a portfolio company and are looking for the few really big winners. You, on the other hand, are trying to build something (team, community, product, etc), and so you will favor slower but safer growth.

I guess in theory you could sell VCs on a high-growth approach and then turn around and say, "Ha ha, fuck you, we're going to keep your money and try to grow modestly." But a) VCs are way better at their game than you are, so they're hard to fool, and b) then you're an asshole, which is bad on its own and also has consequences for future relationships (and future funding). Plus, if you're in a VC-fundable space, you'll probably have competitors who are also taking money, and they'll be able to outspend you on future rounds.

EGreg• 11 years ago

No, assuming you're not an asshole, just want to reduce risk or make your own decisions in good faith, how can they force you to make a decision you normally wouldn't make?

lloydde2• 11 years ago

This takes me back ten years to 2005. I was the QA lead at an open source company and we really wanted to use FogBugz. An operations engineer imported all of our bugzilla issues and we were starting to put FogBugz through its paces, but what we couldn't figure out was FogBugz licensing for all of our OSS community. In the en, I think Joel did get back to us and tell us their product was not a fit.

Another adviser replied to the thread below (oldest at the bottom) that Apache also uses Jira.

In the end we kept using Bugzilla.

  From: bizguy
  Subject: RE: [Staff] FW: Joel Spolsky intro?

I second FogBugz being unreachable. Also, Jira has a MUCH more impressive client list:

Cisco, Oracle, HP, NASA, JPL, CERN, MIT, CalTech, Cornell, HBO

  From: ceo
  Subject: RE: [Staff] FW: Joel Spolsky intro?

in view of the FogCreek people being unresponsive, and advisor's instant "don't use them" response, I'd like for us to do a bit more due diligence on Jira. I notice that they have per-server licensing ($4800), with unlimited users.

  From: me
  Subject: Re: [Staff] FW: Joel Spolsky intro?

jira is java based and requires running tomcat which can be a bit of a pig.

It is supportive of open source communities. That is about all I know about it right now... I will look at it more tonight.

  From: advisor
  To: ceo
  Subject: Re: Joel Spolsky intro?

  Avoid, use Jira... 
  
  ceo wrote:
  >
  > Dear friends,
  >
  > I'm trying to get a hold of Joel Spolsky so we can work out some 
  > arrangement for using their FogBugz bugtracking system.  Please let me
  > know if you know Joel and can help with an intro, since my blind email
  > isn't getting a response.

pbreit• 11 years ago

This is a terribly uninformed perspective on the monumental achievement of large success. If anything, fog bugz "lost" to stack exchange which, imo, is a more profound achievement than the over crowded project management category that still hasn't put out a product that has broad appeal.

spolsky• 11 years ago

Sorry, Prashant, you lost track of the plot of the story somewhere along the way.

(creator of FogBugz, here)

FogBugz won and Jira won, but they were playing different games.

I wanted to make software development better for programmers. When I started creating Fog Creek Software in 2000 programmers were treated like typists. They were not paid very well (my starting salary was $33,000). There was almost no thought around how software should be developed. Companies that scored high on the Joel Test[1] were almost unheard of.

The LAST thing I wanted to do was make another tool of oppression for management to impose gantt charts and deadlines and strict rules about who has to sign off on things.

I set out to make software development better for programmers by blogging[2] and by building a company that would be a great place to work[3].

In 2000 the only way to do that was to bootstrap it. With a team of four people we couldn't build anything complicated. We started with bug tracking software because at least we could touch one aspect of programmers' lives with our philosophy.

FogBugz was designed for smaller collegial teams of people that wanted to work together effectively and needed a clean and simple way to track issues using the smart workflows that small, professional teams like to use.

It was remarkably successful and profitable from 2000 to today. We've never stopped working on improving it, but we also have never abandoned the market of small collegial teams of smart people.

By contrast, Jira was designed as "Enterprise Software" with features to help managers impose specific workflows on teams. Selling Enterprise software is a lovely, profitable business and Atlassian has great success selling to large organizations who ignore FogBugz, but it's the opposite of what I wanted to do. Anyway Atlassian is going public with this enterprise software, good for them, I'm sure they're going to enjoy their well-earned private jets.

But FogBugz was the means, not the ends, and at Fog Creek our ambition was not to be the world's greatest bug tracker software company, it was to fix things for developers. So we kept plugging away at other ideas. Some of them were kinda dumb. Some were moderate successes.

Two of them, Stack Overflow and Trello, were huge hits and spun off into separate companies. Stack Overflow, thanks to Jeff Atwood's inspired leadership, has had more impact on making software development better for programmers than any bug tracker ever will. Trello has grown as popular in three years as Jira grew in 15 years.[4]

Neither of them would have been possible if we didn't have the cash cow of steady FogBugz profits. That's what bootstrapping is, folks! You build one thing and use it to build a bigger thing.

In the meantime I think the world has figured out that programmers are writing the script for the future that everybody is going to live in, so conditions have gotten better. In big cities employers are falling over themselves to invent new ways to pamper and delight their programmer employees, with the massages and the sushis and the dog yoga. We programmers built ourselves hundreds of amazing tools, from github to npm to ci tools, build tools, IDEs, code refactorers, etc. etc. that make programming a million times better than it was in 2000, and bug tracking is just a slice of that pie and not a particularly important or interesting one.

But that said, FogBugz is still very popular and very profitable and thousands of teams use it every day, and we're still reinvesting those profits in making it better and in developing new products to make the world better for developers, and even though it doesn't support pointy-haired micro-managers and doesn't allow you to create a custom workflow requiring that a VP-or-higher sign off on bug reports, there are still small, collegial teams of smart developers who have figured out that this is how they want to work.

[1] http://www.joelonsoftware.com/articles/fog0000000043.html

[2] http://joelonsoftware.com/

[3] http://www.fogcreek.com/

[4] https://goo.gl/hTXXPG

pdeva1• 11 years ago

I appreciate the response Joel and remain a big fan of your blog.

Vendan• 11 years ago

wow, $33,000 15 years ago? That really puts a spin on me making $36,000 6 months ago, working in 4 languages and 2 platforms to build a really complicated SPA web app and mac flash content player system. Glad I got out of that job!

toyg2• 11 years ago

as others pointed out, 2000 is when he founded Fog Creek, not when he started programming. He was in MS when Excel was still competing against Lotus, so that salary is likely from the '90s.

baus2• 11 years ago

From my own personal experience, things weren't bad in the late 90s up to the point of the .com crash. Starting salaries in valley were $45k-$55k. There was a lot of competition for strong candidates, and working conditions were pretty decent. I do commend Spolsky for providing good working conditions in a market like NYC where the current trend seems to be to jam as many people in a space as possible.

aetherson• 11 years ago

I started my career in 1999 at $55,000/yr. Not at a particularly prestigious company or in an important position.

chetanahuja3• 11 years ago

"When I started creating Fog Creek Software in 2000 programmers were treated like typists. They were not paid very well (my starting salary was $33,000)."

OK someone has to call bullshit on this. I started as a lowly software engineer straight out of school at the same time. I started at 70K (east cost, not NY). You lost me right at the beginning there and any desire I might have had to go through your wall of text evaporated immediately.

_pius• 11 years ago

OK someone has to call bullshit on this. I started as a lowly software engineer straight out of school at the same time. I started at 70K ...

Joel started Fog Creek in 2000, but began programming professionally much earlier than that.

hravnx3• 11 years ago

It's fairly sad that the "script for the future" is (partly) being written by people who consider a mere 665 words a "wall of text" that is OK to comment on, but apparently too long to read.

keithwarren• 11 years ago

" I think the world has figured out that programmers are writing the script for the future that everybody is going to live in"

Well put.

btilly• 11 years ago

You may have arrived at this view now, but it isn't believable that you never saw them as direct competition with you.

For example http://www.joelonsoftware.com/items/2009/07/20.html makes it clear that you were adding features so that people wouldn't have to switch to "THE AUSTRALIANS". Which is a pretty clear reference to Atlassian.

tptacek• 11 years ago

The whole quote you're referring to:

    FogBugz 7.0 will include a long list of simple
    improvements that will make life dramatically
    easier for people trying to get things done,
    especially when they want to do things just a wee
    bit differently than we do here in the Land of the
    Fog. Every little feature will be a delight for
    somebody, especially that person who keeps
    emailing us because he can't believe that the
    feature he wants which is obviously only six lines
    of code hasn't been implemented in FogBugz 1.0,
    2.0, 3.0, 4.0, "4.5", or 6.0, and if we don't get
    it soon he JUST MIGHT HAVE TO GO OVER TO THE
    AUSTRALIANS.

That reads like he's making fun of the idea that he's competing with Atlassian, not that he's existentially terrified of competing with Atlassian.

veidr• 11 years ago

I have at times used then-current versions of Fogbugz and JIRA over the past 15 years, and I remember the dichotomy pretty much like Joel lays it out.

I used Fogbugz on small teams, where we didn't have a dedicated person to do things like administer the bug tracker (and where the programmers chose their own issue tracker). When I saw JIRA, it would usually be because there were a lot of layers of management above the programming team (and a need for lots of reports and charts to go into presentation slides), or because the programmers were offshore and not known personally.

That is just one anecdata point, of course. But I think it was always pretty obvious that the two products had completely different philosophies -- and also that they still did compete to a good extent, because after all they are both issue trackers for software development (at least primarily; I guess JIRA also aspires to track issues building your airplane and whatnot).

If those were the only two bug trackers that existed, I myself would choose JIRA if I had somebody else to set up and run it, and Fobugz if I had to do it myself.

hravnx3• 11 years ago

"There was almost no thought around how software should be developed."

Really, Joel? So all the various software methodologies of the seventies and eighties, all the CASE tools of the nineties, Extreme Programming etc etc etc - all of this does somehow not count as "thought on how software should be developed"?!

radmuzom• 11 years ago

He is not talking about software development methodologies, he is talking about the role of people (mostly developers) in the software development process.

lmm• 11 years ago

I don't think it was Wasabi so much as Windows. You didn't have to use Wasabi to write plugins for FogBugz, but you did have to use .net. The kind of people who read Joel's blog run on *nix, and probably have some Java in their stack; if you give them a .war that runs on Tomcat then they know what to do, and if they don't know then there are plenty of open-source tutorials. If you're giving them a .net product to deploy on a windows machine, not so much.

I think the final chapter is yet to be written though. Trello is a joy to use, much better than Jira. And AIUI it's on a much more developer-friendly stack.

toyg2• 11 years ago

"The kind of people who read Joel's blog run on nix, and probably have some Java in their stack"*

I'm afraid you're really off-base there. Spolsky is a MS alumni and his core followers have always been people living in the MS ecosystem. The forums he kept for a while were overwhelmingly populated by people talking of VB and then .NET. StackOverflow was clearly dominated by .Net questions for the first few years.

His choice of platform, when it came to developing his own software, was never really in doubt. Note that FogBugz was not even the actual product he started the company for; that was a proto-blogging publishing platform called CityDesk, which was Windows-only and meant for the general public. FogBugz was an internal tool that he pivoted on, thanks in great part to the cred he had built by blogging candidly on software development matters (at a time when this was very rare).

If you now see his customers as "running on *nix", it's because the world has changed. Now the bugtracker is looked after by devops, people who started working after the wave of cheap Linux server that built the modern web had long settled.

lloydde2• 11 years ago

I'm afraid you're really off-base there. Spolsky is a MS alumni and his core followers have always been people living in the MS ecosystem.

What do you mean by core followers? You underestimate his influence.

I haven't worked in the MS ecosystem in my 15 year career across six companies. I've regularly seen his book around and his writing is referenced from time to time. I'd go so far to say some of those environments I've worked in and some of the people championing his work have been somewhat anti-microsoft.

davidw• 11 years ago

Did Fogbugz really 'lose'? It's not as if bug tracking systems are a winner-take all market with strong network externalities. Granted, it did not 'win as much' as JIRA, but that's not necessarily a loss. One of the cool things about many businesses is that they are positive sum games. Maybe FogBugz works better in some niches and still generates a nice living for the people who work on it.

jeffmk2• 11 years ago

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/

xrstf2• 11 years ago

We used Redmine for a while, but never got the Ruby stack to perform good (we are a PHP shop, so..). I remember the insane version dependencies ("redmine revision x to y needs package P in revision a to b") and that it seemed to stagnate in its development.

In the end I'm happy we ditched it in favor of Trello.

jeffmk2• 11 years ago

Love Trello. I'd like a locally installable version of that integrated with something like Gitlab (maybe this already exists, I haven't bothered to look).

It always seemed a bit slow to me as well. The dependencies issue may be fixed with modern usage of rvm-/rbenv-type things, but I haven't messed with Redmine for a couple years. It's funny you mention the pace of development too; the community actually forked at once point [1], I believe due to frustration with how the development community was being handled. That fork is dead now though.

[1] https://www.chiliproject.org/

nchelluri3• 11 years ago

Having used FogBugz, JIRA, and RedMine, as a developer, my order of preference is:

1 - fogbugz

2 - redmine

3 - jira

I actually found myself pretty comfortable with Redmine's UI and its integrated wiki. Fogbugz was very easy for me to use, but I last used it ~7 years ago.

It may be possible to get JIRA configured so it works nicely, but in general I find I am always running into some kind of workflow issues. It does work, it just seems to take more effort and sometimes me or my teammates come up with ways to work around things that are broken or just not smooth and that we don't have access rights to debug or fix.

amyjess2• 11 years ago

I use Redmine at my current employer, and I really like it. Reminds me a lot of Trac, which I used two companies ago and loved.

By the way, at my last employer, we rapidly switched between a number of trackers. At first, we used Unfuddle for our proprietary projects and Assembla's custom Trac for our open-source projects. Well, theoretically at least; in practice, we did very little with Assembla as a bug tracker (which is a shame, because I love Trac). At some point, we switched to using OpenERP for everything. it was terrible. Then we switched to JIRA, and it was only slightly less terrible.

hliyan• 11 years ago

We recently scrapped Redmine (yes, the UI is horrendous) and started using Gitlab issues with our own labeling system. Working out fine so far.

simoncion3• 11 years ago

I've used Redmine. It's a MUCH better Trac.

Out of the box, it's ugly, but -frankly- who cares? We're all programmers here, and value proper function much more highly than lacquered handles. :)

porker• 11 years ago

Out of the box, it's ugly, but -frankly- who cares? We're all programmers here

Uhh, humans? ;)

I find a better-looking tool to be more pleasant to work with, and Redmine was not-as-painful-but-almost as JIRA for me, for the experience being so poor.

1wd2• 11 years ago

What are the main things it does better than Trac?

Grue3• 11 years ago

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.

martingordon• 11 years ago

My Jira experience was absolutely terrible. We were an 8 person team at time and looking for something more robust than Trello and ended up settling on Pivotal Tracker.

I signed us up for an Atlassian Cloud trial and right away things weren't looking good. I was expecting to dive right in but instead had to wait 30 minutes until my instance was ready or whatever.

They only offer a 7-day trial. How am I supposed to properly evaluate something as fundamental as an issue tracker in 7 days? That's not long enough to learn to use it and then get the team to try it out for a small project.

Worst of all were the 5-10 second load times on each page. I contacted support to see what they could do but they weren't too helpful and I stopped using it 2 hours into the 7 day trial.

xrstf2• 11 years ago

In my experience, most Atlassian products are slow as hell, with Bitbucket being among the faster ones. Confluence can maybe control a space shuttle with all its features, but it's slow to a point where it becomes unusable.

We evaluated JIRA as well, but it didn't work well for people like who are in many different projects at once and don't want to spend days trying to build a view for all those issues (that encompasses swim lanes and such). Also, as you've mentioned, it's pretty slow.

We settled with Trello and are relatively happy.

maxharris• 11 years ago

I had to use Jira at my last job. I could never figure out what it did that you couldn't do in github with less trouble and fuss.

I can't say that I would absolutely refuse to work at a place that uses Jira, but it is definitely something that would make me lean towards another offer.

dannyrosen• 11 years ago

I brought Fogbugz into two organizations (100+ accounts) as a QA Engineer and it worked great -- when it came to bugs.

When we started doing agile (and then "Agile" ... ugh) development the entire process broke down. There were no (good) plugins that could do kanban and moving features from state to state to state dramatically increased the size of an items log. That, along with the friendly, and then suddenly not so friendly filtering lead to our team dropping the product and moving to Jira.

While Fogcreek's "Fastbugz" was a gallant effort in modernizing the application stack and speeding up page loading time, it fell short as it didn't functionality support feature _and_ bug management.

I should note, we had reached out to Fogcreek with all of our requests and critiques but they weren't interested in hearing us out passed the usual account or customer service manager.

mijustin• 11 years ago

What metric are we using to determine who "won" here?

Did Jira "win" just because OP likes it better?

Because both companies are private, we don't really know how much profit either product has made.

chris_hawk• 11 years ago

In reality, it's a double-win relative to the goals each company was striving for - and acheived!

In the author's mind, Jira wins because it's OMG ENTERPRISE and going public.

tbrock• 11 years ago

  This meant they couldn't use all of the ecosystem and amazing tooling around Java

I've never laughed so hard in my entire life.

rsobers• 11 years ago

Won based on what criteria?

Atlassian has over 1,100 employees. When I was at Fog Creek we had ~30.

So if we're talking about profit per employee, I can assure you the people who built FogBugz don't feel like they've lost anything.

dwd• 11 years ago

Surprised no mention of Kiln which was a really nice product when I first used it back in 2008. The ability to inline comments in a code review that then hooked back to the job in FB was fantastic.

GitStash is getting there now, but the Jira integration is still a little lacking.

mangeletti2• 11 years ago

What about the name? He could have potentially left out the most important mistake Spolsky ever made, which is to name a product Fog Buzz. He might as well have named it Rain Smelt, or Lamp Shade. It sounds terrific once you use and like the product, but it doesn't sound remnisent of any kind of successful brand ever. Even the use of 2 words is a departure from the norm. Most of the big brands have 1-word names, and this is not s coincidence. Even Facebook was changed from The Facebook. Brand matters, and names matter.

To play devil's advocate with my own argument, 37 Signals is a bit different as well and people (perhaps more so in the tech community) loved the brand, but the thing is, they used "Basecamp" as their product name.

julianz2• 11 years ago

Possibly your most important mistake is not reading the name correctly. It's Fogbugz. One word.

mangeletti2• 11 years ago

Potatoemuffintrain. See what I did there. 3 words do not become 1 word, simply because the proper spaces are omitted.

I will say though, for many years I have thought the company was called Fog Buzz, (not Bugz).

dragonsh• 11 years ago

I am still not sure if fogbugz lost. In general simple systems are always hard to built.

In general while doing a project with fixed date approach Jira issue tracker is indeed not inline with the source code. So there is a discrepancy between what is in issue tracker and whats in the source tree. Moreover developers cutting corners to meet the fixed date is a technical debt for future and Jira promotes it.

Fogbugz with its probabilistic approach is better matched with the actual source code, since even though developers over or under estimate, its probabilistic distribution analysis puts standard deviation and means put in front of their eyes to do better. So in general fogbugz approach results in better source tree and less technical debt.

atesti3• 11 years ago

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/fogbugz-release-notes

And now just recently there was a little bit of activity, like that they now offer a VM of some kind with the new version. But I think we can't use that because it is the expensive, unlimited user license and they must install it somehow and plugins would still be gone, which we depend on.

And for all of this there is little to no communication.

The stop of "Kiln for your Server" was also done extremely quitely.

atesti3• 11 years ago

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

otabdeveloper• 11 years ago

Programmers hate being held accountable, yes. (This is logical given that they control so few of the risks.)

But in the end, accountability is the reason why you're being paid that salary, not knowledge of framework APIs or algorithms.

Embrace that responsibility and process, don't fight it.

lifeisstillgood• 11 years ago

1. Make a JIRA plug-in that turns JIRA into Fogbugz

2. Profit

Why Fogbugz lost to Jira

Related Stories