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.

> other than the initial hassle of switching to a new system

Is like saying: "people can move overseas with minimal cost (other than shitloads of migration bureaucracy, frequent flying to meet family, put their entire furniture on top of a cargo ship)

More like trying to remove an invasive cancer that has spread to all parts of your body whilst you're still needing to move around, be productive and live your life.

I'd say that for many large companies, Jira is better than the alterntive of having multiple systems that need to be kept in sync. Steering any large company will be a mess, no software will ever make that easy. And any software designed to be that flexible will end up being slow eventually.

I guess the cancer is analogous to JIRA itself, not to the migration of JIRA.

Migrating out of JIRA is analogous to "trying to remove an invasive cancer".

And, since this a thread about JIRA, a lot of bureaucracy

While it is true that Jira is "sticky", the statement was that it did not have a network effect.

MS Word, Facebook, WhatsApp, Visa, they all have network effects: every user you add makes your product more compelling, thus creating a virtuous circle. You need to buy their product because other people have their product.

The network effect of Jira is obviously at the department level; dept. head A mandates Jira. User B gets moved to new dept. C, we need some sort of project management tool - hey B what did you use when you were working for A, oh A likes using Jira, I didn't like it much but it's ok I guess.

Ok folks, let's use Jira!

Dept. Head A moves to Dept. D, hey everyone we are going to start using Jira.

Dept D. is being merged with Dept. E, Dept and new Dept. Head J is joining. E is using some open source Kanban solution based on CouchDB, hmm, let's go to Jira - other departments are also using it and then we can get rid of the CouchDB thing!

In point of fact where network effects of Jira is concerned, I have put some effort into learning JQL and setting up my own dashboards, so when you give me one of the competitors I get grouchy. I prefer Jira or Trello - also owned by Atlassian iirc?

another network effect of Jira is that it's usually set up using AD, so once it's installed and configured, anyone in that org can go and look around without having to create an account.

Jira can have a network effect.

ISO (the standards body) has started using it, I'm sure in part because large companies who contribute to standards were already using it. The committee that I am a member of switched from Bugzilla to it.

JIRA's network effect is the amount of plugins and third party integrations that work with JIRA.

The author points at monday.com: I used it a few years ago and it only has basic and useless integrations out of the box, even for a service like Gitlab. You either develop what you need youreslf of try to so something with Zapier.

What network effects does MSWord have?

Everyone else is using it to write documents, email around drafts, collaboratively edit via OneDrive; sure you can use an alternative, but nobody will want to see a format but .docx, so your alternative is almost guaranteed to be worse than or equivalent to Word. If your alternative stuffs up the document's formatting you become seen as a pain in the neck. So it's just easier to use Word.

Every contract I've received or sent for red-lining uses Word and change tracking. I'm sure exceptions exist, but every lawyer I've dealt with uses Word as the defacto standard for contract negotiations.

You couldn't open a MSWord file without MSWord.

> users can switch to a competitor product like Asana, Basecamp or Monday.com with minimal cost (other than the initial hassle of switching to a new system).

My experience tells me the complete opposite of this statement. Regardless of the the workflows, automation and whatnot there are tons and tons of IP hidden in tickets and over a long enough period references to them end up scattered all over your tools, commits, documents, wikis, IM, email, etc. etc.

When you move ticketing providers it's very likely you can't correctly migrate all of your existing data into the new system without breaking or losing some of it.

I detest trying to figure out why a certain code change was made, looking at the commit message only to find a reference to link to a dead ticket.

I'm not for or against Jira, but moving ticketing systems does not come at a "minimal cost" in my opinion and needs careful consideration and motivation.

Coupling, it's a constant scourge all over in software.

Whilst I LOVE to crap on Jira, it has brought some magnitude of order and civility to the PMO's and at least created a familiar work environment for people.

God help me If I ever have to go back to word docs and sharepoint to manage project work.

Yes - JIRA is almost a textbook example of lock in. Moving a large company's workflow would mean months of disruption.

Any tool has lock in. How much work do you think would be involved in moving from perforce to git, or from Bamboo to CircleCI?

I was (a very small, and only part-time) part of a team that did a migration from a Perforce-era VCS to git. It was about 6 weeks of 100% background work -- as in, we prepared cheat sheets, changed or rewrote relevant parts of the CI and deployment chain, while everyone in the company kept using the old VCS.

Then it took about 36 hours to move the relevant code bases (a few dozen repositories, some of them 20+ years old) over to git, including the entire commit history. This was pretty slow. It could have probably be done faster but we figured, since we only do it once, we don't need to invest too much time. We scheduled it on Saturday morning so it would be done by Sunday afternoon and we had some time to test it before Monday hit the earliest timezones.

We had a backup plan in place in case it didn't work but it wasn't necessary.

The two repos were automatically synced for a while, to allow people who had started work on something on, say, Friday morning, to commit their changes to the old repos, rather than have to replay their work on the new ones. After that the old repos remained read-only, but we preserved them because, obviously, our issue tracker had twenty years' worth of references to old VCS revision numbers.

So it took about 6 weeks of indulgently part-time work (our infra team worked several hours a day on this, I worked... about an hour or so a week?) to plot this daring plan, and about two days to make it happen. The total amount of work disruption was likely non-zero but certainly small enough that most people didn't complain of anything other than having to learn git.

I can't say about Bamboo to CircleCI but, having gone through one of these, I can say with 100% confidence that if you start out right -- that is, your existing repository is not a mess of stale branches and weird merges -- and you don't go about moving fast and breaking things, moving from even an ancient revision control system to git is not really apocalyptic.

Thank you for sharing your experience. Migrating from software A to B is part of life, Jira does not hold a special technical place. Politically, that's a different conversation...

You are right. I'd say politically it is equally likely to have Jira replaced some places as it is not replaced in other places.

Oh, yeah, politically that took like four years to happen, if not more.

Not if there is an open protocol with multiple conforming implementations.

I helped a prior employer move to github and asana through JIRA's own APIs. It's actually not that hard and the entire engineering group was very cheerful of the change.

Really? Was it easy enough to define mappings between all the various fields/ticket types etc? I guess you could do it per-team across an organisation.

It always seems hard enough to get information out of JIRA using JIRA when I watch our PO in planning meetings.

Yup, there was some mess around inexact mapping so we had our own conflict resolution and definition of what and how to interpret respective fields.

Honestly, JIRA easily has one of the most sluggish and horrid developer experience so the bar wasn't too high to begin with. Visual Studio Online / Azure DevOps is far better than JIRA ecosystem imo.

Be curious what the size of the engineering team and company was.

Asana is great for SMBs but for larger developer teams it lacks a lot of features and integrations.

(Work at Asana so I might be biased)

While Jira may have some unique features for developers, one of Asana’s selling points is how it allows non-homogenous teams (incl whole companies) to work together (and by themselves within individual teams) on a variety of different kinds of work (projects, processes, loose day to day tasks etc). And as for scale we have many customers with thousands of users (one tech customer of ours has 100,000+ users on Asana - most of them I’m sure would be product teams).

> (other than the initial hassle of switching to a new system).

that's doing a lot of work in that sentence!

>> with minimal cost (other than the initial hassle of switching to a new system)

The first part does not realistically connect to the second part. Surely the author is aware that switching to new systems is actually quite expensive monetarily and operationally - definitely not “minimal”?

At my old company, they had two annoying jira workflows management wanted to tie in to the dev process

1) When the user wants to merge to master, at least one of the commit messages must reference a valid Jira ticket.

2) A Jira plugin was installed such that when tests were run in CI, a jira ticket was created to record the result (pass/fail). This somehow ticks a SOC compliance box

1) sounds pretty reasonable and standard to me, though a backdoor is usually necessary for PRs that are just to fix a build-blocking issue due a bad merge e.g. Agree 2) is stupid, why would you need a ticket for a passing build? And unless you have a super stable CI system a decent % of failures are transitory and don't need tracking - but if your master branch fails to build on retry an auto created blocker ticket makes sense.

How’s that working when Jira is down for almost a week and there is next to no feedback about the outage

I was about to write the exact same comment - quote the bit where they say Jira has no network effects and add "LOL" after it.

How out of touch can you be with the stickiness of enterprise SaaS, and still write financial commentary?

Funny how the network effect is rephrased in terms of cost of switching, instead of the more benign word of mouth etc.