Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The thought of running a 10,000+ development team using Basecamp is hilarious in its insanity.

Because that is where Jira primarily plays. In enterprise companies where it's rolled out across the organisation with tentacles firmly embedded into almost every process and system.

And whilst people continue to criticise Jira it continues to grow because in reality it competes with products like Rally not Asana. And there really isn't anything out there that can offer the same level of customisability and flexibility.



That should be the usual environment for Jira. However the only company I saw using it was a two people company with less than a dozen of consultants. That was in the early '10s. I was definitely not impressed by the UX, inconsistent, slow, apparently designed to make it hard to learn. Other companies I worked with later on (no more than a couple of dozen of people) use Kanbanize, Asana, TeamCity + YouTrack and yes, also Basecamp. On the development side, anything among GitHub (but no Actions yet), Bitbucket (plus Pipelines), Travis and custom stuff with a fair dose of Good Luck /s.


Every bank I have worked on in any capacity has had Jira in some form. So perhaps it's a little more industry specific than one might think.


Indeed Jira scales a lot (although being slow) and is well customisable and flexible. Its plugin system is also great (although a better documentation of how to develop/maintain one, and of their APIs would grealy help).

But in the meantime, it requires increasing discipline and regular revampings of internal processes across dev, product, market teams, and that's a lot of energy to burn to make it "work" across an org.

Even more when you have people that are for very strict and precise adherence to processes.

Whereas a less flexible, good enough system could help funnel the same energy towards something more productive than just internal compliance for the sake of it.


Which is why Jira continues to sell so well.

You simply can't force one way of working on larger companies even if that way is undisputedly the right way. Because a lot of people will need to sign off on which tool to purchase and each of them are special geniuses with their own special genius way of working.


Well, time will tell.

I'm not opposing a single Jira methodology to a myriad of other ones (tools or processes).

I'm saying that Jira, without being constantly challenged for what it is[1] creates its own growing and tiring bureaucracy because companies (even large ones) cannot agree on a right way to work (but will add piles over piles of bureaucracy).

[1] exactly like what Agile methodologies, or some certifications are; where now it feels like almost no one remembers/knows how to organize teams _without_ resorting to anything that Agile-thinking has tainted.

It somehow relates to the fact that, in some companies, more energy and money is burnt over how to organize the work rather than doing the work itself. And it definitely shows.


For real, I don't think it's all about "each special snowflake's way of working" but there are legitimate needs that change

Each team can have a different workflow with Jira

Jira works for non-software-development tasks as well

I've seen it used on companies having 4/5 levels of stories deep (think Initiatives/Epic/Stories/Subtasks/etc. Different companies split this different ways.

The plugins sound inconsequential but they are very useful (almost a must) in several occasions.


The thought of running a 10,000+ development team using Jira is horrific.


The thought of running a 10000+ development team is horrific.


The thought of running is horrific.


Think of how much human effort is being wasted on Jira!


It is just a ticketing system with a very robust business process engine.

Most complaints I’ve heard about Jira boil down to the horrible processes people choose to implement in it.


Thats the rub too. Jira setup in a simple way is what most people need. Yet you get process people in there and suddenly you have 50+ fields to fill out before you can even start working on something. Then another 20+ fields to fill out to close out a ticket. I went from taking 2-3 hours total to plan out a sprint, to it taking 3-4 days and many meetings. And no one can tell me how these fields are used day to day, what are they trying to solve, and how it was better than what we had. If I wanted to do waterfall I would not be having 2 week sprints and this process would be wildly different.


My (cynical) experience is that those fields are simply there to generate arbitrary metrics for the process people to show to higher-ups to demonstrate that they are “managing” the project.


Feudal-like political jockeying for power produces this nonsense. I've been beleaguered with such nonsense for most of my 28-year career, working in 3 Fortune 250's. It certainly doesn't help that JIRA is designed to be flexible enough to be all things to all people for all purposes. And that's why CIO's love to buy it.


The same thing happens to orgs using Salesforce, custom fields get added and ignored ad infinititum.


People really underestimate the loss of productivity and morale of using slow web-based tools. Now multiply it for 10k.


> Because that is where Jira primarily plays.

Is there a breakout of company size vs revenue for Jira? Because for the past 10 years I've worked only on smaller companies and they all, no exceptions, used Jira as well.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: