Live data from Hacker News

Why Fogbugz lost to Jira

movingfulcrum.com

141–150 of 251 posts

Re: Why Fogbugz lost to Jira

#141
post #130

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

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.

Re: Why Fogbugz lost to Jira

#142
post #50
post #37

Earlier quoted context omitted.

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 con…

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.

Re: Why Fogbugz lost to Jira

#143

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

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

Their sales team is their partner network. VARs.

Re: Why Fogbugz lost to Jira

#144
post #79

Earlier quoted context omitted.

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

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

Worth it for the concept of technical debt refinancing.

Re: Why Fogbugz lost to Jira

#145

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 aro…

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!

Re: Why Fogbugz lost to Jira

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

Re: Why Fogbugz lost to Jira

#147

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 ( ht…

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?

Re: Why Fogbugz lost to Jira

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

Re: Why Fogbugz lost to Jira

#149
post #147

Earlier quoted context omitted.

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

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

Re: Why Fogbugz lost to Jira

#150
post #147

Earlier quoted context omitted.

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.
Post reply on HN