Why Fogbugz lost to Jira | Hacker News Reader

Why Fogbugz lost to Jira

movingfulcrum.com

312 pointspdeva1243 comments

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/

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.

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.

I was at a job where we did that in the early 2000s.

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.

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.

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.

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.

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

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.

Try TargetProcess ... Gets very little attention. But hits that sweet spot for me at least.

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

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

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

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

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.

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.

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

Previous HN discussion (~200 days ago): https://news.ycombinator.com/item?id=9182814

Also worth a read for a chuckle: http://www.dadhacker.com/blog/?p=2267

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

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

Frankly the valve is often quality. Quite often something ships on a date. That something is usually crap.

In order to get schedule to change, you'd have to convince salespeople to do something. They are generally the ones doing the convincing.

In order to get the features to change, you'd have to get a product manager to give up what they want to build "because of technical reasons". That doesn't happen often.

But if the product ships with the new features on the agreed upon date, the only people hurt are the developers and the customers. Most people in the business who pretend to care about the customer experience are perfectly happy to do this because it gives them a big club to wield over the engineering team in future iterations.

A classic "pick two" situation: Fixed Ship Date, Fixed Scope, Fixed Quality.

More like "pick one".

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

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 the date arrives, ship whatever terrible garbage you happen to have and declare victory. Spend the next N months "fixing bugs", which mostly means "finishing half finished features".

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) change the deadline, (B) move feature A to next release, (C) remove some other feature". In the absence of any other guidance I'll direct the team to follow the plan above. Happy to discuss further.

I've always found this is a pretty effective strategy. Big companies aren't often dumb, you just need to know how to operate in them.

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?

Both. The times I have seen it, it has been an endemic cultural problem, but most managers participate fully in the madness.

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.

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.

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.

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

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

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

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

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

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

An aside: Any other podcasts to recommend?

As far as technology related, I listen to Coding Blocks, RunAs Radio, Hanselminutes, Software Engineering Radio, Herding Code, .Net Rocks. Always looking for more though.

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

Worth it for the concept of technical debt refinancing.

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

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.

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?

Do you really want to inherit autogenerated code? I doubt the autogenerated C# would be nearly as easy to understand or read as the original Wasabi code. I also think writing CLR object code, if it's anything like writing assembly, would be much easier to generate than C#.

Well, it is what they eventually did, after ten years. With tons of tweaks to make it spit out natural-looking outputs. I just don't understand why they didn't go that way from the start.

I was unaware of that. I'm still betting they didn't go that way initially because of the inherent difficulties of autogenerating C# code.

From the linked HN comment:

> the C# code was not human-readable

> to transform the PHP wholesale into valid C# once

I'm not quite sure what you mean; PHP was only ever a target; there was no source in PHP. It was something VBScript-esque being compiled to both ASP (later C#) for Windows and PHP for Linux. This started, of course, long before Mono.

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.

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

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

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.

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

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.

Right and now think about who is going to control the JIRA install: the manager or VP or CTO.

Fogbugz's interface prevents this kind of crazy customization and thus it acts as a defense against the craziness. For a custom workflow with Fogbugz you have to grab a plugin. To get my manager to install a plugin for JIRA took weeks (and I still never got access to the REST API or approval for one plugin months later). So Fogbugz is developer-friendly because it makes it harder for a manager to go in an lock things down and mess around. With JIRA, the micromanager seems to be bundled with JIRA... ;-)

Managers find a way. They will just use (or invent) another tool that lets them do it how they want. Now you have two tools, and some poor schmuck (or the developers) will get stuck with the job of keeping them in sync.

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

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 they can't provide one "comment markup" language to all applications.

So far as I can tell, they did have one common markup syntax for all applications... but then Confluence users wanted a WYSIWYG mode, so Confluence now uses an XML-based format internally, and Stash is a Git tool and 90% of the Git ecosystem loves Markdown, so Stash had to use it too...

These things are not mutually exclusive.

Markdown embraces HTML, and so a WYSIWYG mode based around HTML is compatible with Markdown.

Markdown's weaknesses for table design, image insertion, and complex layouts is all handled by HTML and WYSIWYG tools that edit that directly.

That would have solved the Git scenario, and the Confluence scenario, whilst having a single highly predictable markup across all of their platforms.

The problem really stems not from these problems being addressed per product as if they existed independently of all other products. But that's a terrible approach, as few people buy just Confluence without JIRA or Stash, people buy Atlassian because a consistent suite should work better than many myriad tools that don't quite know how to interop. Atlassian's strength is the consistent and integrated approach, so the UX should be focused on strengthening that.

That's because almost every Atlassian product started off at a separate company that was then acquired.

Was that really the xkcd you wanted?

I actually misread the URL as https://xkcd.com/927/ (having memorized that number like everyone else here, I'm sure) until I saw your comment. #277 is definitely not right.

#277 sure seems to me like a reasonable reply to "Whoever designed <such and such> deserves a special place in hell", which is what it was posted in response to.

yes

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.

Confluence used to use markdown and wysiwyg, and about 5 years ago abandoned markdown to reduce development costs. They have a lot of non-developer users using Confluence, who aren't good with things like markdown. Our shop didn't like it, of course, since we were all capable of markdown and wysiwyg is never actually wysiwyg.

I could be wrong, but I think it used textile (I believe Confluence predates markdown). I'm not sure it matters a whole lot, but if you wanted markdown it's likely you would have felt underwhelmed with textile.

Sorry, yes. Confluence had a markup language. it didn't use Markdown.

I fully agree that it's well past the time to switch to Markdown. That and the dropdown things are my main annoyances with JIRA.

It does make sense when you think about the context though - JIRA pre-dates Markdown by two years (according to Wikipedia) and Markdown has only got really popular in the last five years. Back when Jira's text formatting came in, everybody was doing their own thing...

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

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.

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

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

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.

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.

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.

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.

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.

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

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

Does the opposite kind of user exist? Has anyone ever met a fanatical JIRA lover?

In my experience there are only people that tolerate JIRA on one side of the spectrum and a bunch of people that hate JIRA on the other side.

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.

Can you please elaborate on this configuration? What is the general nature of the configuration changes you're making? Or, how is your workflow affecting the product. I ask as I am in an organization right on the cusp of implementing JIRA, and I would love to steer the implementation team toward a more useful configuration than the clunky defaults, with which I've had prior experience.

The biggest things for me are:

* Setting up several statuses (more than in the default) to reflect backlog, selected, in progress, testing, deployed

* Creating an appropriate board which splits everything into columns by status and rows by user

* Setting up a few quick filters to find things like anything which has been in the backlog for more than 6 weeks or bugs which haven't seen activity in the last 48 hours

* Integrating GitHub. Being able to kick a ticket over to QA from your commit message is awesome.

Beyond that, I mostly focus on stripping out default things to make the workflow simpler. I don't need my software to enforce that I can't move a ticket to deployed straight from in progress, and stripping out those extra rules makes it easier to deal with.

Much appreciated. That's a great opener for a discussion with our impl. team.

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.

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

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.

I've used Mantis and Bugzilla and I'd also take JIRA over those.

JIRA is the best bug tracking software I've used since I left Microsoft, which was over a decade ago. Sometimes I still miss Raid, particularly it's ability to build complex queries, but also the ability to connect to any team's project. At the time, it was supposedly the only internal tool used throughout the entire company.

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

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

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.

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.

> Unless it's Atlassian themselves

It is

> they're probably being cheap and giving it as little resources as possible and

Almost certainly

> it not being on-prem probably contributes to the feeling of slowness.

Sure, all of 150ms of it really adds up.

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.

There is no universal solution. Every product will have users who find it hard to use. Speaking out about the fact that you find it manageable is valuable information and may show that there are more users who find it easy to use than not.

I agree. Things for some people, they don't work for others. But you cannot blame users and say "oh its how you configured it" "its good out of the box" etc.

If its failed for 1 user, its a shit product. If its a success for 1 user, it's a great product.

It's GOOD for a user to say they find it easy and why.

It's GOOD for a user to say they find it hard and why.

1 helps the user give a product a second chance by learning of his pitfalls.

1 helps the company improve their product to make it easier for more users.

My point is that apologists shouldn't come in here and blame users for a shitty product.

> If its failed for 1 user, its a shit product.

That is a dangerous over-generalization.

Let's say -ferinstance- you have kick-ass, seriously best-at-what-it-does software that's only localized in Japanese, and a uniglot USian attempts to use it. They're gonna have a hard time. The software will very likely fail them, because they will be unable to understand anything they're being told by the software.

Does that make the software shit? No. No, it does not. The software is great, it "just" needs to be localized in order to be great for a wider swath of humanity.

Maybe I'm being misunderstood.

From the perspective of the user, if the product fails for that user, its a shit product.

I don't mean the product itself is actually shit.

Like I say:

If its works well for a user. It's a great product. If its fails for a user. It's a shit product.

From the perspective of that user.

But we can learn from both the users who like it, and the users who hate it. But we cannot blame the problems the user has, solely on the user.

> From the perspective of the user, if the product fails for that user, its a shit product.

Honestly, even this is a hazardous over-generalization.

I've looked at gobs of software that failed to do what I needed it to do. Much of that software was good-to-great at what it was written to do, but it -like a lot of software- wasn't written to do what I needed it to do.

That doesn't make the software shit, that makes it unsuited for my needs. I am -and many others are- clever enough to distinguish between the two categories. :)

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

Yet Jira is a wildly successful product.

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.

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

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

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!

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.

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.

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

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

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.

That sentence construction certainly implied otherwise. Even disregarding the part about starting salaries, the implication that programmers were treated as "typists" circa year 2000 is preposterous. This is around the height of the first dot.com boom and tales of extravagant programmer salaries was already legend. Starting his argument with such a patently absurd claim just discredits everything else he says later on.

it is over 100 degrees outside, the world is round.

so does that mean if you don't agree with me that it's hot out where i live at this point in time and space that you don't agree that the world is round?

opportunity is different for different people in different places at different times. No need to be so flippant because he relayed his experience with you.

starting salary of 70k is pretty darn lucky without experience, many developers started out much lower than that and they still do. The point is the corporate attitude towards developers has changed greatly since 2000; from my view point i agree completely.

try starting out making 18k a year and then come post how much you feel valued.

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.

The comment was on the preposterous claim that programmers were treated as "typists" around the year 2000. It's as if dot.com boom has just been collectively erased from all the downvoters' memories.

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

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.

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.

A compelling theory, but the Inc article he wrote in 2009 pretty clearly states that he considers them direct competition and laid out a plan to beat them.

This did not happen.

And now the plugins are gone :-( With the new GUI they do not work anymore. I was so excited when the plugins were released, it's a great SDK and we were quickly able to write two plugins that we really needed

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.

"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"?!

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

If you think the software methodologies of Olden Times did not consider the role of people in the software development process you are mistaken.

They might seem archaic (and even wrong) when we look at them today, but still: smart people put a lot of thought into the methods, they were hotly debated among professionals, books were written, and consultants made money teaching and preaching them.

In other words, not that different from today.

There have always been people who thought about how to make software development better, but there were far fewer of them, both in software and in management. Relative to what we have now, I think it's absolutely fair to say that there was almost no thought about it.

Even ten years ago I was convincing my co-workers and manager that we should be able to run our build without human intervention; today I would not believe you if you told me your team had that problem, let alone that people disagreed it was a problem.

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.

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

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?

We used it recently as a kanbanish/scrumish board for a recent development cycle and it worked out pretty well. We had separate boards for each sprint, and a backlog board that contained some broad-swipe categories. It would definitely be nice if it had better integrations with fogbugz (which our team also uses) or other bug tracking platforms, but I imagine it would be challenging to do that and maintain its extreme ease of use/simplicity.

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.

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.

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

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.

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.

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

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

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

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

From sour grapes?

Their sales team is their partner network. VARs.

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.

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.

This was my experience, with Redmine instead of Fogbugz.

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

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.

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

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.

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)

Doesn't Atlassian claim not have a sales team?

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!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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?

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.

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.

The only reason I looked outside of GitHub was Bitbucket's free private repos.

Now, for our academic lab, we're working entirely with Bitbucket (for the UI), and repositoryhosting (for low-cost repo archival with many users).

In an academic setting, where private repos are created for each small collaborative project, then left idle but accessible, GitHub's per-private-repo pricing model is prohibitive.

BitBucket has better user and permissions management for businesses, although github is slowly improving.

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

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

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

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?

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.

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?

To get the money from VCs, one has to sell them on the notion that the company will to scale until it can swallow the moon. Suppose I take their money and say, "Sorry, now I want to reduce risk! Too bad, suckers!" I'd say that makes me an asshole.

If you've taken a small amount of their money, then maybe they can't legally force you to take more risk than you think is wise. (They can, however, make sure you're unlikely to get money from anybody else, either now or in the future.) But if you've taken a B round or more, then a founder probably doesn't have control.

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/

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.

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/

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.

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.

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

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

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

What are the main things it does better than Trac?

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.

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.

  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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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

Where can one get a job as a professional FizzBuzz developer?

I think if a program is big enough to devote a software developer to it full-time, it's going to have at least 10 bugs. Maybe they are small or unimportant or so obscure that none of the users actually run into it, but they're in there somewhere.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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.

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

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.

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

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

2. Profit

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

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.

They're actively marketing their blog on HN -

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

You're right, I hadn't even considered the Fog Creek blog, but the article specifically talks about Joel on Software.

And Atlassian's blog seems to be in the same ballpark as Fog Creek's: https://news.ycombinator.com/from?site=atlassian.com

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

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.

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

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.

Ruby, Perl, and Python weren't meant to be in-house languages created to support a commercial product. Not to mention that in their infancies as hobby projects, they didn't have to hit sales deadlines.

Reply on news.ycombinator.com