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."
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.
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
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.
> 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.
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:
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.
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
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
Yes, I regularly contemplate the possibility that they all secretly hate me for using software which you don't like. All their appreciation and thanks for moving us over to Jira is surely a facade for their secret plot of hate.
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.
* 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.
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.
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.
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
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.
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.
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.
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.
> 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. :)
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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".
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.
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.
"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."
> 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.
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.
>> 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.
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.
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!
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.
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).
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.
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.
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.
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.
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.
250 comments
[ 2.9 ms ] story [ 95.6 ms ] threadhttps://www.reddit.com/r/programming/comments/3n2sc1/why_fog...
> "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."
http://hanselminutes.com/493/killing-off-wasabi-a-20yr-old-v...
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...
> the C# code was not human-readable
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.
1. Content Marketing
2. Sales Team
https://news.ycombinator.com/from?site=fogcreek.com
And Atlassian's blog seems to be in the same ballpark as Fog Creek's: https://news.ycombinator.com/from?site=atlassian.com
Java? I believe that should be .NET.
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.)
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.
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.
As a PM, Pivotal Tracker (used in a previous life) is one of the best work-tools I've ever used.
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... ;-)
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.
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.
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...
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.)
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.
[1] http://trac.edgewall.org/wiki/TracUsers
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.
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.
I much prefer the UI used in Trac and its clones (e.g. Redmine), which is simple and straightforward.
[1] https://www.atlassian.com/licensing/purchase-licensing
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 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.
In progress could mean anything from writing specs, ui design, dev or testing
Micromanagers can screw anything up - you can invent some pretty insane workflows using the FogBugz workflow tool, if you want to :)
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.
https://twitter.com/jesseherlitz/status/648557144845910016
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.
With just a little tweaking (30 minutes or so on a fresh install), I can have it perfectly configured to match my ideal workflow.
I'm guessing you meant this as a joke, but such jokes come across as personal attacks, which are not ok here.
* 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.
As a result, all issue trackers have more detractors than promotors, with the vast majority of users being neutral.
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.
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.
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
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.
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.
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.
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.
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.
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.
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. :)
Yet Jira is a wildly successful product.
I wish they improved their Mercurial support. I believe they have only one guy handling all of the Mercurial issues.
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.
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...
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...
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.
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.
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.
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.
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.
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.
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.
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.
https://github.com/facebook/react/issues
They are using the issue tracker for all sorts of things, and it clearly has value.
http://yarchive.net/comp/linux/bug_tracking.html
and the kernel seems to be doing pretty well.
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/
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.
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.
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.
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.)
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
No. Good luck persuading the management to try something else!
> 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
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).
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.
> 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.
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".
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.
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.
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.
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.
"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."
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.
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.
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...
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.
I hate using JIRA, though, just like I hate using all Atlasssian products, so it would have been nice if FogBugz won.
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 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.
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.
With that said, Spolsky (although I think a lot of his writing is fantastic) rarely addresses his mistakes.