Also, a fresh JIRA install with no issues, projects, or anything has a memory footprint of over 0.6GB.
I don't know why people use it, but people do. My guess is that all the effort it requires provides a simulacrum of control and productivity.
I will give you this - _should you chose to_ fully mastering it's screens, issue types, screen schemes, issue type screen schemes will take the better part of few hours to completely map in your head. Jira gives you amazing flexibility to do almost anything you want on the issue type level, but with that flexibility, comes an very complex model.
When I first encountered it, I was exasperated that I had to take those couple hours to draw the hierarchy and map it out in my head - but now that I know It, I'm happy it's there.
I agree there is improvement here. But in my years of experience with JIRA, I do find that most software development teams approach things differently, and so there is no 'one size fits all' for most dev teams.
One team wants saved filters to be front and centre, another RSS feeds. One user creates a hundred issues a day (usually QA), whilst others rarely create issues at all.
My main memory actually was of poor fit and finish. Just a tiny thing but every time I logged in, no matter how, it offered to remember my login. Every time, I clicked that box in hope. It never once worked.
I can assure you that it works now :)
What is the default timeout on 'remember me' in JIRA, if you'd know please?
I had to deal with both products at my last company and maybe it was just how they set it up, but entering a bug into Jira was ridiculous. Finding anything was worse. It was probably the most user unfriendly piece of web software I've ever had to use.
Confluence? Ugh. The WYSIWYG editor was questionable at best. I had hours of fun cleaning up pages with big tables that were edited by multiple people. And seriously, a hierarchical wiki? Do you know what you get when you have a hierarchical wiki? A wiki that has almost no inner links because no one can remember what the path is to any document.
Again, it could have just been how they set it up, but I just feel like they threw every feature and the kitchen sink into that product in the name of "flexibility."
What I'm finding about the hate-on I'm seeing from some people about Jira, is that they CLEARLY have never, ever been forced to deal with the pain that is remedy as an issue tracker. Jira is like a breath of fresh air, a touch of heaven, compared to that product. I have a 50 bullet-point list of unresolved issues with Remedy. My issues with Jira are tiny-corner cases problems that 99% of users wouldn't even notice.
- does not handle workflow well
- does not clearly manage changesets
- does not clearly track codebase changes at an audit level
- allows too much meaningless configuration and reporting
TFS is much better solution and it's not even the best on the market.
Serena is a much better solution and it's not even as good as TFS.
Jira is not an enterprise solution. It's a toy for non-developers.
And if you are a public company, you sure as HELL better not be thinking that's an audit standard that will satisfy SOX.
But some of your comments are describing features of an SCM "managing changesets", "tracking codebase" - TFS/Serena are full fledged SCM suites - and, I'll agree with you right now, they are definitely perceived as enterprise worthy systems.
But Jira is a lightweight issue tracker. It can link issues to an SCM (and indeed, fisheye/crucible are great additions that we use to connect to perforce) - but, at it's heart, it's an issue tracker.
Re: Workflow - Yes - could be more sophisticated. In particular, last time I tried, I couldn't find a way to (easily) gate an issue with multiple voters - that is, if I had an issue that required approval by five departments before it could move to the next stage - couldn't do it in Jira, and that's a pretty common use case for Workflow - so they have a ways to go. With that said - there are workarounds - JRA-10042 was a way of delivering equivalent functionality. Also - The 4.4 Visual Workflow Designer is elegant (and included in the base package of Jira)
Re: Meaningless Reporting - Problem is, what one person's "Meaningless report" is another person's "Must have" feature.
But, the overall theme of your comment, that Jira is not a heavy weight enterprise product - is accurate. It's functional, fast, and has a beautiful interface, and, for $12,000 for the unlimited user Greenhopper+jira package, is basically being given away for free to companies, and, at $10 for a 10 user license - is for all intents and purposes, free for individuals.
I've thought long and hard about this, and (to bring this back on track) - I've decided that Jira is such a beautiful product, is so elegant, and is so versatile, precisely because Atlassian _doesn't_ charge very much for it and doesn't have sales people or "Technical Account Managers" - large corporations paying seven or eight figures for software, expect to have some ability to influence the feature set, and, if you just charged someone $10mm+ for a product, you feel somewhat obligated to do so. And so your software ends up being this huge crappy enterprise system that yes, is fully SOX compliant, and is completely ITIL certified - but honestly - is just an absolute mess.
I'll state my position: I don't think there is a commercial issue tracker that I've seen, that can track issues, as effectively and beautifully, as Jira can, at any price.
Finally, it may have changed since the last time I used it (it's been about 8 years), but it had limited issue<-->code checkin integration (which is critical) and I don't even think Agile tools are part of it's vocabulary.
Nice ticketing tool, and, if Jira wasn't available in a 10 user license version, RT and Trac would be on my shortlist for quick-n-dirty ticketing tools for smaller software devel shops.
With 142,000 "generic issues" tracked to date (mostly software and network support, with 1 to 100s of replies per issue), we haven't run into a wall yet.
We don't use RT as our primary software dev tracker. We use it as a generic issue tracker.
I _LOVE_ Jira - I find it to be the greatest extensible issue tracker out there, and, after extensively using both it, and Remedy (a tool which costs on the order of $800,000 to do an enterprise install, and another $100,000/year to support, and is therefore popular in the enterprise) - I can say with some authority it outperforms Remedy in almost every category.
There is zero doubt in my mind that if someone is looking for a flexible issue tracker, that Jira has to be final-3 consideration in any down selection.
Ask me anything about Jira - I live, eat, and breath the product.
Confluence 4 has a completely rebuilt rich-text editor with autocomplete - the ease of use of a WYSIWYG editor with the speed of an IDE. Love your thoughts on it when it ships.
FishEye is also pretty decent although it chokes a lot with the size of our repository - we have a lot of code and a lot of branches which have really pushed the size up. A few JS optimisations would be nice as well - it can really chew up the CPU sometimes.
This feature request is our second highest voted issue (JRA-4446), and one that I personally want to see fixed. For the moment, there is a 3rd party plugin that solves most use cases (Structure Plugin from ALM works).
The key for us as a vendor is making it work without degrading the overall experience. We have seen plenty of other issue trackers implement this, but it really detracts from the overall experience when you don't know what is a task, or a project, or a feature etc.
But we're definitely trying to find a solution.
On FishEye - we have it working on code bases that have hundreds of millions of lines of code, but it often requires some tuning. For example (and one of many such examples), in older versions of Subversion, there was no real way to tell what was a branch, and we rely on 'conventions' such as /branches/ to tell this.
Unfortunately, every code base contains 'mistakes' where someone copied the entire tree into /branches/ or created a branch somewhere else.
There are some easily configured settings that usually make FishEye run a lot faster but explicitly telling it about some of these cases.
But - even saying that, performance was around 50% of the last few releases of FishEye, so the latest versions do run significantly faster in all instances.
Our branches probably put us in the hundreds of millions of LoC category. It's unfortunate that for a long time we were prepared to allow each of our customers a separate branch for each release - each of which potentially has active development on it (not a real branch I know as we don't intend to ever re-merge them). As such we have a lot of code that potentially needs supporting. I'm not actually sure how often they are searched on as I'm lucky enough to work on newer parts of our software but the idea of dropping them from FishEye didn't go down too well.
I believe the guy who did the setup spent some time messing around with performance - I have no idea if he did everything right but he's a pretty smart guy.
I'll definitely take a look at the most recent release though, thanks for the tip.
Oh and thanks for taking the time to reply to my unsolicited feedback!
- time tracking
- detailed planning/reporting (we use Greenhopper)
- customer service (hiding projects and fields for internal use)
- integration with version control
By far, my biggest complaint to Atlassian is upgrades, which are a huge PITA. There has to be an amazing new feature for me to go through that.
Just as a FYI - the latest version of JIRA (4.4) and the soon to be released (next week) version of Confluence (4.0) have had the install and upgrade process rewritten from the ground up.
If you've been bitten in the past, I'd strongly recommend taking another look.
A summary of the features here:
* Time tracking: http://trac-hacks.org/wiki/TimingAndEstimationPlugin
* Planning/reporting: simple trac reports + wiki dashboard.
* Customer service, we have a separate trac instance with Intertrac set up between so you can link tickets.
* VCS integration: works with hg and svn fine
Is it a Jira issue, or has someone created an overly restrictive workflow, complex data entry screen?
I'm not sure if you can blame the product for how it's configured by it's users, particular when the default configuration is pretty bog simple and easy to use.
What about Jira do you hate? What about other members of your team?
I'm genuinely interested - maybe I'll see something in a different light.
- When I login the widgets that show me what issues I have are pretty useless. They don't show my progress/logged work, they don't show what you last worked on. The priority icon is kinda tiny. So I feel like I am having to track some information manually or in my head.
- If you start work on a new task and try to log work, the log work action is hidden under a menu. And when you do log work, it doesn't automatically set the issue to "In progress".
- Creating new issues is also a bit annoying. First it's hidden in a menu. Then it is a 2 step process. The first form is completely silly. You have 4 inputs, Project, Type, Next and Cancel. Did that really warrant it's own page?
- Subtasks are also a bit crazy. Once you enter your subtasks it's hard to reorganise and prioritise your tasks. It's actually simpler to use vim or a text editor when planning out work and then enter the issues into Jira when you are satisfied.
- No subtasks of subtasks!
Certainly when I read ghshepard's several comments, I think "wow, okay, if you're a much bigger heavier bloatier organization, with much more byzantine needs from an issue tracker, maybe this thing actually has some value!"
I eventually got superuser privileges, and spent a lot of time myself trying to figure out how to beat it into getting out of our way and just tracking some frigging tickets. That's a week of my life I'll never have back, with no benefit to anyone.
At some point, management decided to double-down, and renew our license, to get an upgrade (I think to Jira 4.0, since this decision was late 2009). Oh my god. For one thing, we wasted SO MUCH TIME on that upgrade. And for another, the dashboard started taking 30-60 seconds to load, because it's suddenly full of clever (read: not clever, not performant) AJAX. And I still don't remember getting anything out of it.
Please, Jira, just get the hell out of our way!
At this point, if Jira was the only product on the market, I'd rather use one huge text file to track tickets, shared via svn or git. It would offer less useful features, sure, but it'd also offer way way less pain.
The main argument anyone could give was that it would have features not present in our other issue tracker, RT 1.0. Uh, y'think?
Short summary of my experience: on my small team, in a small company, with no experienced hands to manage it quickly and efficiently, Jira is a big bag of slow-down pain, with nothing to recommend it, and I'd rather use NO tool than use THIS tool. $10 for 10 users sounds like about $1000 too much.
Oh, and don't get me started on Confluence. I mean, less pain than Jira, but ZERO useful features (relative to free pain-free alternatives). Why would you ever choose this over Mediawiki? My new company uses ikiwiki, and that's beautiful, and it clocks in under 25kloc of Perl.
On the other hand, I've never seen an instance of Fisheye deployed for an OSS project that didn't take minutes and minutes to load a single page.
What did you find particularly horrible about them, and what tools do you think do a better job at those aspects?
FWIW, one of the reasons I love both of them is they're the only tools of their type that I've been able to throw a non-tech person at and they can use. When roping the spouses into helping out, that counts for a lot.
We also use Crucible, which is a great code review tool, and Confluence, which I don't really care for, but I don't really dislike it any more than any other wiki software.
We are a manufacturing / media / distribution company with billions in revenue.
Now, Confluence? Not a big fan. Tried it, ditched it.
My FINAL experience with JIRA + Fisheye + Greenhopper + Crucible nearly made me cry. This is on an 8 core Xeon, 12Gb RAM, 15k SAS RAID and Ubuntu 10.04LTS and Sun hotspot VM.
Random failures, null pointer exceptions all over the place that took us out for a couple of days, incredible memory usage, 8xCPUs jammed at 100% due to race conditions, Fisheye only barely just about works in Google Chrome because it's so slow, useless paid support, horridly slow and inconsistent UI, MyISAM tables causing relation failures (!!!!), don't even talk to me about their plugin management - it's a crock of shit.
I couldn't recommend it at all. It's worse than Visual Source Safe.
That's as a JIRA admin. As a JIRA user, I get people saying "can we have Trac back please".
If anyone at Atlassian is listening, please sort your product out. It's not fit for purpose.
The hardware we have installed Jira ranged from a 1 Gigabyte VM with 8 Gigabytes of Hard disk, up to a 2 CPU Dual core server.
90% of the time with mySql as the backend, 10% of the time with HSQL
Operating System has been whatever the LTS variant of Ubuntu, or the more up to date version of RHEL (or CentOS as the case might be)
JRE has always been the most recent version from Sun.
We only use fisheye and Crucible internal to our company, but that accounts for 60% of my experience.
In the last four years (and 10 or so versions) - I've never had a random failure or null pointer cause a failure. It's been the most reliable software package I've ever used.
Interesting that we have two completely polar opposite experiences.
One of the bits of infrastructure I never have to worry about.
edit: never tried any of their other products however. We use Pulse by Zutubi for continuous builds.
You didn't try and use it with the built in database or something did you?
For a public example, https://issues.apache.org currently has 209560 issues, thousands of users and it works fine.
#1 rule of Jira is make sure you have enough memory to keep the mySql Database in cache. The attachments don't matter so much.
What I love about the (Lucene?) index is that I can still do a free text search of all 118,000 issues in under 1 second, the same as I was able to when there were only 100 issues. Plus, the 4.x JQL (kind of a simplified Sql Variant) makes it easy to do ludicrously complex searches that still return in basically O(1) time.
DavidU - tell me a bit more about your trouble with Jira Scaling - was it case of the backend system not having enough memory? Jira isn't really disk speed limited, so that's about the only thing that could cause you problems.
Did you get a chance to run the typical performance tools to see if you were CPU, IO, or Memory Bound?
People actually like Trac? I thought people used it because it is better than Bugzilla and is free.
Sorry if you feel the support is useless. We try our hardest but that's your opinion and you're entitled to it.
However, saying it's "paid" is flat-out wrong. No customer ever pays for support from Atlassian. It's included in the license fee. Free support to current customers is the only type of support we offer.
I keep meaning to take time out one of these weekends to profile and determine how to mitigate this, but it's just not a priority.
Are you positive switching to the postgres backend will help when there's almost no concurrency and the slowness is persistent and deterministic?
How are you hosting it? I'm using Apache 2.2 with mod_wsgi on Ubuntu 10.04LTS. Don't use mod_python - it's terrible.
It's just that they are not Atlassian employees but are Atlassian partners employees. Atlassian has a massive partner/reseller network these days
You have a cap of licensed users, but no way to view only users who are burning a license (we had open registration on our Confluence install for a while, so many employees made 5 or 6 accounts - the only way to figure out which ones are still enabled and which ones aren't is to manually click through every fucking one), things like that.
I love the feature set of Confluence, and feel like it is generally pretty easy to use and well-received by my users, but I dread the annual license renewals (and the upgrades that automatically start sending your users mail with no way to opt out of that globally -- that you have to install, because they contain security fixes.)
Not every company builds products that they might need internally, and even among those that do, their use of it may not match the usage patterns of ideal customers.
Mr Ford's reasons for not talking to customers though is a lot better than "you don't have time"
What really kills me about all this is your customer almost certainly understand the competitive landscape, problem space, and industry better than you do. Maybe every other entry failed because they tried to read between the lines rather than delivering what people want.
That's not to say your product should be built as an amalgamation of every feature request thrown your way. Balance is key. But thinking you know better than your customer might not be a great strategy.
So feature: I want a faster horse
Requirement: Get places faster, and without stopping for rest periods
New feature/tool: <profit>
Something that doesn't shit all over their yard might actually be more important than speed, but they wouldn't even begin to think of asking that because it's not a possibility in their world.
What do you want in the next Blackberry? "real touch" and "real browser" were pretty far outside the box when the iPod touch launched..people weren't asking for it because they didn't know they wanted it (or that it was possible).
RIM did this. I was a Blackberry to iPhone convert, and I bet a company that was willing to listen to me could eventually figure it out. I would have asked for a browser that actually worked, a larger screen, and thin enough to fit in my pocket (rather than the ridiculous belt clip I had to wear). I had no idea we were capable of the iPhone when it came out, but sounds like my checklist doesn't it?
But my overarching belief about product design:
- build stuff you are passionate about because you use it
- listen to customers, but don't do what they say
The reason that products all start to look the same is that customer's only experience of 'better' is a competitors product. That's why you have Audi's advertising about their safety record, and Volkswagon's advertising about their performance features.
A great read on this topic is Youngme Moon's book different:
It's interesting to contrast with the model Netflix seems to use, which is "Don't give people gym memberships, give them the money and let them sort it out." Attracts different types of folks I guess, everybody has their preferences.
I'm pointing out that culpability in a perceived bad job performance isn't a two way street and it would be responsible to speak about how you don't always get it right. nothing is more irksome then someone who has fired dozens of people and says they made the right choice every time. statistically impossible.
For whatever reason, only the bottom 5% ever get fired. Where organizations tend to make the mistakes you are talking about is during layoffs, in which quite often, the wrong person is let go - but, in "theory" layoffs aren't performance related - though, in practice, they almost always are. Top Performers are almost never laid off, despite their role in the organization, and bottom performers somehow always turn out to be redundant. One exception to this is when a company drops a division or location - then it's across the board.
There are two points that I have taken from the TopGrading process:
- hire people who are 'A' players who have succeeded at whatever they have done AND who have a passion for the role you are hiring for
- past performance IS the best determinant of future success, and the best way to answer the first question
The interview process generally starts at college where you dig into why they chose their course, the highlights, where they excelled, where they failed, who influenced them and why. Did they take on any leadership positions? Win any awards?
Then for each job they have had since, find out - why they chose it, what they found, what they fixed, what they learnt & what they would do differently. Would their boss give them a reference, and why did they leave.
At each turn, you are looking for: 'were they an A player / had outstanding results' and 'does their career path lead you to believe that they will be passionate about this job'.
There's a lot of nuances to it, but I wouldn't hire senior people any other way. I recently compared our hiring notes to a comprehensive personality test of a new employee, and they matched exactly.
What used to be (I think) a $700 plugin now adds $2,000 to the annual maintenance cost of JIRA.