
Jira Is a Microcosm of What’s Broken in Software Development - davetwichell
https://linearb.io/blog/jira-is-a-microcosm-of-whats-broken-in-software-development/
======
tensor
"Though I think of Jira more like a spreadsheet. Very useful once upon a time.
Outdated now. Static. Manual."

This statement is so blatantly wrong that it actually put me off even reading
the rest. Spreadsheets are stronger than they've ever been and are never going
away, let alone being "outdated." Sure there are products that claim to be
"the next spreadsheet" but most of those actually serve a different purpose:
no-code app dev.

~~~
pm90
If you’re going to make judgements so easily you’re going to miss out on a lot
of good ideas that people put out there.

~~~
Clubber
I would say 90% of tech ideas that area floated out there are awful and I'm
being pretty generous with that number.

~~~
loeg
I also tripped on this sentence. But the article is not bad if you charitably
read "spreadsheet" as "spreadsheets for bug/project tracking."

------
GCA10
OP sounds like someone who's unhappy working on big software projects. That's
understandable. But once you're on a big project, you can't keep it all in
your head. You can't make your own clever adjustments when problems arise
without documenting everything and then taking it through channels.

For what it's worth, sales people have the exact same complaint. They can get
testy, too, about executives using software-oversight tools to take away the
soul of what they really do. Allow me to change 15% of the words in this
piece, and it could become a rebuke of Salesforce and its siblings, as applied
to large sales organizations. So the brief allusion to sales seemed way off
base.

Process can be exasperating, until you've worked in a big place where there's
no coherent process.

~~~
pragmatic
No jira sucks. Azure DevOps spoiled me. Going back to jira is painful.

Is not the process, it's the broken tool. Broken file uploads, general
wonkiness and all the minor irritations that just don't get fixed.

Managers choose jira. Developers will create a process but will choose tools
that work.

------
vosper
> This blog is not about how Jira is too complex and over-engineered with
> features I don’t need.

This blogpost is a microcosm of engineer arrogance (it's also an ad for their
product, so all of this is basically a strawman to drive sign-ups. Great
content marketing, to bash on a tool people love to hate).

The world is not all about engineers. Jira is a tool for whole companies,
which have lots of other departments than Engineering, which are also
important, also trying to reach their goals.

I'm so sorry that you got pulled out of your "deep flow" state because an
executive is trying to figure out if a project is at risk. You know, she might
have a really good reason to worry about that, maybe including information you
don't have, like a potential customer who is at risk if the feature doesn't
ship.

So suck it up and help out your colleagues.

And if you don't want to be interrupted, then maybe keep your tickets up-to-
date, or proactively communicate risks, or sign out of Slack for a few hours,
or get your manager to do their job better and be a buffer to protect you from
interruptions. None of this is Jira's fault.

Can Jira be a PITA to use - sure, but that's probably because of how your
company set it up. You can make Jira streamlined if you try, but it takes
active administration, and the people who work in Jira need to be empowered to
work _on_ Jira. If you can't get your Jira project to work the way you need,
then that sucks, but that's probably Jira being a microcosm of your company's
org/power structure, which is a different thing.

Or sign-up for their product, that's really the goal of this post.

Edit: I did not intend to claim that all, or even most, engineers are arrogant
people. They certainly are not, at least in my experience. If you are an
engineer (I am one, too) please don't read this as me attacking you
personally! I am aiming at _this kind of blog post_ , which displays a me-
first attitude that I think is unhealthy.

~~~
commandlinefan
> engineer arrogance

And this is the twilight-zone reality that software developers are forever
stuck in:

Manager: "I need you to integrate the TPS reports with JIRA for a client"

Developer: "Ok, I can look into that"

Manager: "How long is that going to take? Put some story points on the JIRA
task."

Developer: "Well, I've never done that before, so I'll have to do some
research and I can't really say for sure-"

Manager: "I need you to say for sure. Knock it off with your engineer
arrogance and suck it up and help your colleagues. I'm so sorry that I pulled
you out of your 'deep flow' state but we're trying to reach our goals here"

Developer: (heavy sigh) "Well, a week maybe? If I can focus on just this and
not all the other things I'm currently tasked with-"

Manager: "No, subtask it out to individual tasks of no more than four hours
each. And you'll need to spend an hour every day in a status meeting so you
can spend five minutes updating the status of your subtasks and listening to
everybody else's unrelated statuses".

~~~
xmprt
I've never seen a manager operate like that and if yours does then you should
look into moving.

~~~
commandlinefan
Maybe I've had a 30-year string of bad luck.

~~~
phendrenad2
Considering the litte morality play you typed out includes the exact
"developer arrogance" and "flow state" quotes from the OP, I'm guessing this
is an exaggeration in anger and it's impossible to argue with until you
provide a non-exaggerated example of your 30-year work environment.

------
pianoben
I recognize that this is a marketing blog, but it blames Jira for what are
really culture problems and/or bad management practices.

This is an emblematic quote:

    
    
        Take subtasks, for example. The invention of Jira subtasks is an affront to dev teams. Clearly someone who has never spoken to an engineer on a dev team created it. It’s the least dev-friendly way possible to get insight into what’s happening with a Jira story.
    

Behind the bombast, the author assumes that the purpose of subtasks is to
provide micro-level insight on progress to PMs. I agree that this would be a
misuse of subtasks. Speaking as an engineer, I _love_ subtasks because they
help me keep track of my various efforts towards whatever feature the ticket
is tracking. Also, I'm the one who defines them!

Jira isn't anyone's favorite software, but it is so configurable that it ends
up being an embodiment of your dev process. If you hate it, chances are it's
because you hate how you're managed.

~~~
frobozz
Yes.

I've used Jira for years and never understood the hate.

The only times I have had real problems have been with particular
idiosyncratic configurations or conventions that someone at my end has put in.

~~~
danielscrubs
Have you tried the alternatives like YouTrack?

The Jira UX is amongst the worst in the business.

And yet... there it is, on every workplace with an useless operations team.

~~~
frobozz
I'm not saying Jira is great. I'm just surprised that people, particularly
ICs, _hate_ it.

------
cj
I spend hours per day in Jira. Half as a PM, and the other half as an IC.

I've never used Jira Classic, so can't comment there.

But Jira Next Gen projects have been great to work with. So much functionality
and bloat is stripped out of Next Gen, sometimes too much was removed I think.

I hear people hating on Jira very often, but at least the way our company uses
it, it's great.

The only thing I'd really want to change is (1) performance, page load times
are frustrating, and (2) ability to easily move a ticket from 1 project to
another project without clicking through a 6 step process.

Edit: Regarding Jira's slowness, I'd highly recommend trying the Mac app which
is dramatically faster than the web ui.

~~~
laurent92
> performance

By Atlassian’s ToS, you are not allowed to « comment on the performance of the
products ». I know no-one thinks this would be enforced here, but I just want
to highlight that it doesn’t help a company to improve if they know they can
just lawyer-up a problem away and avoid benchmarks and being compared on that
topic.

~~~
ceocoder
This is from Atlassian's ToS

 _(d) incorporate any Cloud Products into a product or service you provide to
a third party;_

does this mean that I can't integrate JIRA into a ticket tracking workflow
that I build for my product with IFTTT that creates a new ticket when someone
sends an email to a support alias?

 _(e) interfere with or otherwise circumvent mechanisms in the Cloud Products
intended to limit your use;

(f) reverse engineer, disassemble, decompile, translate or otherwise seek to
obtain or derive the source code, underlying ideas, algorithms, file formats
or non-public APIs to any Cloud Products, except to the extent expressly
permitted by applicable law (and then only upon advance notice to us);

(g) remove or obscure any proprietary or other notices contained in any Cloud
Product;_

Fair enough.

 _(h) use the Cloud Products for competitive analysis or to build competitive
products;_

Sure, I mean this is hard to enforce but if the team at Trello was using JIRA
while making Trello, Atlassian could just say "hey - stop, no like".

 _(i) publicly disseminate information regarding the performance of the Cloud
Products;_

Seriously? I really didn't believe when I saw parent say _you are not allowed
to comment on performance of the product_ but I stand corrected. I will not
comment on performance of any Atlassian product ever, ever ever. You got me
Atlassian, this is what I get for not reading ToS before clicking Accept.

 _(j) encourage or assist any third party to do any of the foregoing._

Ok.

[0] [https://www.atlassian.com/legal/cloud-terms-of-
service](https://www.atlassian.com/legal/cloud-terms-of-service)

~~~
AstralStorm
Wow, that's as dumb as clauses get.

I'll try to get the legal team on it. It's a landmine as even a casual
discussion of performance voids the license. Any discussion of outage may or
may not involve this point.

It is a devops prevention clause.

~~~
jgalt212
> even a casual discussion of performance voids the license

Of course, that assumes such terms are enforceable. But, even if not, just
having them in there is just so odious as to make one seek out other
solutions.

~~~
inetknght
Oh of course performance matters. But privacy? Atlassian's privacy policy is
even worse.

------
ghostpepper
Does anyone else find it pretty obnoxious that this site changes the window
title back and forth between "Jira is a microcosm of what’s broken in software
development" and "(1) New Message!"?

Is this a bug? Who thought this was a good idea?

~~~
ErikAugust
That website is "a microcosm of what's broken" with websites.

Here is that content without that:
[https://beta.trimread.com/articles/32605](https://beta.trimread.com/articles/32605)

~~~
SilasX
Lol yes! The fixed floating header, the pop-up modal after a few seconds, the
long load time for text/image content...

------
cloudengineer
Jira is a workflow tool, which also means that most of the issues mentioned
here, can be sorted out between the PM and devs on who the workflow should be,
and what the rituals for updates should/could be. Jira is flexible enough to
accomodate it (mostly). From a developer perspective, some of the points maybe
valid, but not from PM perspective.

It would also help if we could get an idea of what the alternatives are, that
are better

Edit: Also looks like marketing for the product, than a valid article on Jira
pitfalls.

~~~
boudin
I'm using Jira, not a huge fan (mostly because it's slow, the cloud version at
least) and there's some clunkyness BUT every time I looked for alternatives it
was either too opiniated (like SCRUM or nothing) or had really poor
integration with dev tools. The big advantage of Jira is that you can
customise it quite a bit and it has a good set of integrations and APIs.

I'm still thinking of moving away at some point but haven't found any
alternative...

~~~
pm90
Try clubhouse

------
csneeky
After working on more than 20 green field projects over the 25+ years I've
been a software engineer I can tell you that yes... all SDLC management tools
suck at times, but also can be a great part of something very productive. It's
how much they are tailored to the needs of the team and how practical their
consumption is. I've been a part of projects where JIRA is a nightmare and
part of projects where it is a blessing. Same goes for Trello, Asana,
Confluence, "just github", etc.

I've also used JIRA where it is ONLY managed by the engineers and also when it
is owned and managed by large teams of non-engineering stakeholders.

My 2-cents: When a project isn't going well it's the team that is deficient,
not the software, in 99% of cases. Most of these tools can be customized (and
combined with other tools if needed) to create something that works... and
this varies on a project by project basis. It's not about the tool... it's
about how pragmatic and adaptive a team can be as they apply them. Panaceas do
not exist in this problem space.

------
seanjregan
Hi Sean here. I work on Jira at Atlassian and I also met with Justin and the
Jira Admin for his company prior to this article. I've also heard from him
since. He was not consulted re the use of his comments. Generally, I'd
encourage vendors to seek permission when citing a customer in marketing in
this way. It's a simple respect that can be paid with low effort.

I thought it might be helpful to share a few thoughts on the article. To do
that I've added annotations on the article itself using Hypothes.is an open
web annotation service. This lets us have a conversation right over the
article. I've added a dozen or so comments, gifs and links to help add color
from the Atlassian POV.

You can view my comments and add your own via this link or find me at
@seanjregan on Twitter.
[https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fj...](https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fjira-
is-a-microcosm-of-whats-broken-in-software-de&group=__world__)

Usually we don't engage in the annual articles by competitors that pin SW
industry failures on Jira but in this case it seems a lot of what we've been
shipping in Jira Cloud is perhaps still unknown. (And, this annotation tool
seemed well suited to this sort of dialog.)

Much respect to the LinearB team. Anyone working to make SW Development better
is good in our book. Great products will stand out on their merits among the
dev community.

While riding the Jira coat-tails via blog titles is a common approach to
generating traffic, I want to also note that Atlassian is very open and we're
happy to partner with any vendor that can make dev life smoother.

We partner with GitHub and GitLab as an example. If they can do a better job
or a customer prefers their tools then it is on us to 1.) Support them and 2.)
continue to up our game.

-@seanjregan Add your feedback, comments or Jira tips to the article here. [https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fj...](https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fjira-is-a-microcosm-of-whats-broken-in-software-de&group=__world__)

~~~
linknfg182
Hey Sean, Dan here and I wrote this blog post.

Thanks for the effort on the detailed response!

We have a core value at LinearB to empower the dev community and I can see you
share a similar passion. The tone of my blog post came off more critical of
Jira than intended and it’s great to see the improvements your team is making.

Although LinearB is not a Jira competitor, the issue remains that once story
planning ends and coding begins, development teams are left with a major gap
to stay up to date in real time to support the hundreds of micro decisions dev
teams have to make every day. We are eager to address this problem!

It takes hyper correlation between Git and project management tools combined
with a developer first mindset (not project management).

Since you are open to partnership, I will reach out to you so we can meet and
pursue!

Thanks again Sean.

(I also responded with the annotation tool you used here:
[https://hyp.is/A_Sb1N2gEeq1_E8AuivgVQ/dzone.com/articles/jir...](https://hyp.is/A_Sb1N2gEeq1_E8AuivgVQ/dzone.com/articles/jira-
is-a-microcosm-of-whats-broken-in-software-de))

------
t0mbstone
I hate plenty of things about JIRA, but I'm flagging this post because it's
incredibly biased (written by a direct competitor to JIRA), and their site is
also extremely hostile to users with their messaging notifications.

~~~
moretta
Yeah it almost reads like a comparison piece. Pretty much all of the points
relate back to the fact developers are adding manual updates and how the
competitor solves it by integrating Git PRs and commits. However that's easily
possible in JIRA now via the integrations (e.g. GitHub) and automations to
close tickets depending on the status.

Still, even then with the automations in any of this software to show VCS
updates you're going to get managers asking for updates depending on your
environment.

------
henning
At least Jira doesn't make popping noises and then show a banner ad that
covers the entire page after 10 seconds.

------
jasonpeacock
Usually Jira sucks because it's not setup correctly to _support_ teams'
workflows, instead it's used to impose workflows on teams.

Jira can be as heavy or lightweight as you make it, but most of the suffering
I see is because the way teams work isn't being supported by the Jira
owners/admins.

~~~
pseudalopex
Sounds like a microcosm of what's broken in software development.

~~~
stock_toaster
Agreed. Jira exemplifies the “you’re holding it wrong” software.

------
chadlavi
I used to think Jira was horrible. Then I moved to a company that uses
Pivotal. Now I know what horrible means.

~~~
riffraff
my feeling to this day is, to paraphrase Churchill, that Jira is the worst
possible project management software, except for everything else.

------
kstrauser
I don't have a problem with Jira directly. It's not great, but I've yet to
find a project manager that's amazing so I can't say it's substantially better
or worse than the alternatives.

That said, I really don't want to work with a PM who _loves_ Jira. It's so
flexible and configurable that it seems to really call out to a certain type
of PM who adores adding lots of process for the sake of itself. Can we make a
43 step workflow starting with "preliminarily claimed the task", "read the
requirements sheet", "read the associated documentation", "opened an editor",
"ran 'git pull'", "created a new branch", etc. etc. etc.? You bet we can! I've
worked with PMs who really wanted that level of granular visibility into
project status, even though it greatly slowed down the work of actually
getting stuff done.

So in my experience, you have PMs who _love_ Jira because it gives them a
level of control that I absolutely don't want to be involved with, and PMs who
think Jira is "eh - it's alright". Atlassian's problem with the latter is that
they're just as likely to say "eh, Pivotal is alright too".

There needs to be a Heisenberg's Uncertainty Principle for software
development: measuring a process is guaranteed to slow it down, so there's a
spectrum between "fast chaos" and "corporate paralysis" that you have to
consciously select for, and you don't get to pretend that "fast and tracked to
the tiniest detail" is something that's possible.

(Side note: Confluence died for me the day a new version removed the option of
editing page markup directly. Up until then, I had a workflow that converted
Python module documentation to Confluence wiki markup and uploaded it. When
that went away, I vowed never to use it again until it came back. Has it come
back?)

------
devnull255
At the company I currently work for, Jira has become yet another opportunity
to engage in metrics abuse. Probably because Jira makes it easy to create
reports and dashboards that are more useful for managers than for delivering
software.

The company, which has "committed" itself to "embracing agile", has
implemented some new employee performance policies which clearly demonstrate
those decision makers don't know wtf agile is. One such policy is tying
performance to "individual velocity" or story points per sprint per individual
completed. Some managers, especially my current manager, care more about
individual velocity than what velocity is supposed to be used for.

Consequently, developers can be raked over the coals if their individual
velocity dips below a pre-determined number. When my manager confronted me
with my lackluster individual velocity over the last few sprints (shown by a
Jira report), I first tried to convince him that team velocity mattered more
and that it was supposed to be a metric used for planning work for a sprint,
not as a forecast metric. I tried to get him to see that velocity for everyone
would improve when we got better at prioritizing and creating stories that
allowed us to deliver value each sprint. It would also help too if we could
function better as a team. But he wouldn't have any of that. I just had to
improve my personal velocity.

So I learned how to use Jira better. I created pointed stories in the backlog
I knew I could finish in a sprint and meet my forecasted velocity. The next
time my manager ran his Jira report, he remarked on the improvement. The
amount of work I actually did didn't change, but my individual velocity did.

While I agree with the premise of the OP about Jira. I would go even further
than just Jira and say that today, proficiency and mastery of any tool used in
the software development lifecycle seems to be more important than knowing how
to do software development right.

------
natchy
> _The current software delivery process revolves around pushing decisions
> down to dev teams and forcing engineers to push status updates back up. This
> system ensures executives are the only ones who have context and can see the
> bigger picture while engineers do all of the work._

> _This is backwards. It holds us back from building the best product and
> slows us down from delivering faster._

Thats engineering. If you don't like it then try to make a career move into
management or product or start your own company (not advised).

I myself had to come to terms with reality and have been making the
transition.

You got one life, no use complaining until the day you die. Move into
management and make the changes. If you're ambitious enough, you should have
learned all you need to learn from engineering after 6 years and can apply
your knowledge in a more strategic role, running circles around non-technical
PMs.

~~~
yishaibeeri
_> Thats engineering. ..._

Engineering really doesn't have to be like that. I've worked for companies
where the leaders took care to push context down, not decisions. When done
right, results are very tangible, and (most) of the devs much happier. A few
devs struggle and feel lost - probably the ones you want least on your team.

~~~
natchy
> push context down, not decisions

whats the difference? either way the context or decision is defined by someone
else, and you're still the one swinging the hammer.

I actually think there's a major problem in engineering where many don't take
charge of their lives and want to guide the decisions. Its a weird Stockholm
syndrome love-affair with being the engineer. Idealism is also a problem ( _"
it doesn't have to be like that."_).

> (most) of the devs much happier

yeah, but not the ambitious ones I was talking about.

I'm not knocking engineering, I'm saying it's a stepping stone in your career,
and not a long term place if you want to influence trajectory within a
company.

------
bachmeier
I briefly used Jira, but I couldn't handle the extreme slowness. You click
something. Then you wait. And wait. And wait.

~~~
laurent92
Cloud or Server? It seems a lot of companies’ reputation were broken by
clients installing their software on 2GB/1.5GHz servers with HDD, and Cloud
will help at least getting a consistent measurable experience of the same
product for everyone.

~~~
CyberDildonics
In what universe is a few billion instructions per second not enough to
respond to a single click?

~~~
laurent92
In OSGi universe. Making software which does one thing well is the easy part.
Making extensible software with plugins is super-hard.

~~~
CyberDildonics
It has been done many times over the last 25 years. I think that's a pretty
thin rationalization to having a program freeze when you click a button.

------
commandlinefan
What seems to be lost on too many people - including people who really ought
to know better - is that 90% of the time, software developers don't know
_exactly_ how to accomplish a task, but know how to figure out how. There are
two classes of "estimates": "that will take a few minutes because I know
exactly what's involved" and "I'm not even entirely sure exactly what's being
asked for here, but it sort of 'feels like' this other thing that took about
three days that one time before".

------
fivre
My struggles with Jira are more that the people who should be in charge of
configuring it effectively and running it smoothly (team managers and PMs)
often don't. I see a lot of stuff that's incredibly inconsistent and a lot of
features that are used incorrectly (most prevalently using labels for
EVERYTHING, usually using 4 different labels for the same purpose where say, a
component or Epic would make more sense). Exacerbating that is that these ad
hoc half workflows aren't communicated effectively, so the only people that
understand the systems are their creators

Jira's complex, I get it, but lots of things are. Jira's docs are decent
enough--certainly decent enough that following the tutorials will grant you an
understanding of the various tools and their intended purpose--but people
seemingly just don't read them. Some things just aren't going to be fully
discoverable or clear through UX alone.

More galling is that these are usually the same people that then create shadow
PM empires through Excel spreadsheets of their own design, which is just ugh.
So much blame is heaped on Jira that's probably better blamed on ineffective
management.

~~~
jgust
This, exactly. All complaints about JIRA boil down to poor administration, not
the tool itself.

------
stefan_
Well this was disappointing when it turns out this was an advertisement for
what looks like clowns building the ultimate micromanaging platform, complete
with profile pictures and little status tags and progress bars.

------
unixhero
Learning Jira and accepting Jira both classic and NG has made me so much
money, as a team leader, architect and program manager.

Jira is the user plane for interacting with project items, however like others
here said, everything else must be solved with clear communication, frequent
ACKs with team members and so on.

Yes, Jira Next Gen is nicer. But classic works fine too!

Also Jira can be a lot of other things. It's really flexible.

~~~
eddieh
But at what expense? Does Jira ever frustrate you? Imagine how it frustrates
developers that hate working with overly complex time-sink software. I can
change my email client. I can change my text editor to my liking. I can change
nearly any other tool I use, but when a company uses Jira, I'm trapped using
something that mostly gets in my way.

~~~
unixhero
I don't have the choice. I am just a cog in the wheels and it helps us do our
job.

It's not really in the way, if that's the case it sounds like your processes
or workflows are messed up.

I've had days where I don't want to see it, but that's because I'm tired of
working. In those times it quick to blame Jira.

~~~
eddieh
Oh definitely, the places I’ve worked have used Jira as a crutch for broken
processes and workflows.

------
blakesterz
I really dislike using JIRA, I struggle with it for all the reasons there, and
more. But...

"Though I think of Jira more like a spreadsheet. Very useful once upon a time.
Outdated now. Static. Manual."

Are spreadsheets really outdated now?

------
ngngngng
I think the author has made the ever common mistake of confusing correlation
and causation. Bad engineering orgs often use Jira, but Jira does not cause
bad engineering orgs.

Anecdotally, the most frustrating company I ever worked for had obsessive Jira
practices, but there was so much wrong with that company I could write a book
about it.

------
TedDoesntTalk
> Take subtasks, for example. The invention of Jira subtasks is an affront to
> dev teams.

Really? Not to me, although I’m not clear when to make a subtask or start
using an epic.

~~~
AstralStorm
Generally subtasks are good when it's a single well defined feature or problem
and then they are few. To be used sparingly. They're best used like keynotes.

Epics are for broad developments, looser defined. Best used as "bags" of
tasks.

Sometimes epics might be disabled altogether and then you have only subtasks,
and labels get to be misused as the bags of tasks. I personally consider that
a pathological setup. It is much harder to work with and JIRA query tools
don't work as well with it.

------
spelunker
Nice blog post about your new platform I guess.

I do remember working on projects before Jira. My first job out of college
managed their software dev lifecycle with Bugzilla. I assure you, it was much
worse.

Jira isn't bad, it isn't great, and I honestly don't waste much thought
thinking about how bad it is.

------
ninjakeyboard
Jira is very customizable in how it's used. It's sort of like saying that a
wall with sticky notes is a bad development tool because of some anecdotal
experience. It all depends on what you do with it. Maybe it's more like saying
that a spreadsheet is a bad tool.

The only thing I resent jira/confluence etc for is dropping its markdown
because it was too hard for the company to maintain :) But they're working on
it again. Confluence is probably one of my favorite tools but I haven't used
jira in ages as it's possible to get by with github these days.

------
wolfgke
"This is the root of the issue. Jira was made with project managers and
product managers in mind. Not dev teams. Project and product managers
(collectively referred to as PMs going forward) are the primary buyers and
owners of Jira. Not engineers.

Engineers love simplicity and efficiency. Jira is the polar opposite of that."

Why shouldn't project managers and product managers love efficiency, too? If
the tools allows the engineers to do their work more efficiently, the
development speeed of the team increases - this is what makes project managers
and product managers look good.

------
tetha
Hm. To me it sounds like they are ranting about micro controlling by too much
detail in the jira. Sure, if you have to close 6 tickets for the same line of
thought, it's annoying. So don't do that.

And on top of that, the new jira automation + smart commits make stuff much
smoother. Assign yourself a ticket, push some stuff with the ticket ID to
auto-progress to <in progress>, commit something with "EXA-042 #close" and it
auto-closes. Took us some time to get there, but now it's a smooth todo-list
for the team.

------
csours
To paraphrase many of the comments here: Most of the problems that devs have
with Jira are not problems with base Jira, but with the implementation and
usage of Jira.

Jira is perfectly fine, just like ALM is perfectly fine, TFS (Azure Devops?)
is perfectly fine, Trello is perfectly fine, etc...

The problems come from the implementation, and the implementation is
reflective of the culture. Any work planning tool becomes a work tracking tool
and any work tracking tool becomes a punishment tool (without careful and
attentive work to stop this effect).

~~~
hinkley
It's not the fall that kills you, it's the sudden stop at the bottom.

It is perfectly reasonable to blame the agent of chaos for the chaos that
results.

~~~
csours
ehh, but this is kind of like blaming the results on hitting concrete vs
hitting a cornfield. Yes, you might have a slightly less bad time hitting the
cornfield, but the height of the drop is the more determining factor.

~~~
hinkley
My point is that people love to let Atlassian off the hook. They set up the
conditions for failure. You can't blame all of the consequences on the person
who touches it last.

It's really the same class of externality that we used to blame Microsoft for.
You can try to collect all the cash and all the fame and then blame stability
and usability problems on third parties, but not everyone is going to buy it.

If you weren't pandering in the first place, you wouldn't have all that cash
or fame. You knew what you were doing. Even if you don't want to say it out
loud.

------
nooyurrsdey
I've never understood the hatred for JIRA - it includes a ton of features that
many find useful. Yeah it's a PM tool but you need the ability to organize
boards and workflows at scale in larger organizations. It's not a tool
intended for your startup that can manage with Trello or Github Projects.

This reads like the usual developer's opinion of "the world is not built for
me" and "I don't like it if developers aren't thought of first"

~~~
foobarian
It's not just a PM tool. There are hundreds of examples at our company where
e.g. developers documented various tasks in Jira tickets including steps to
take, commands to run, things to watch out for, that benefited me greatly.
Sometimes the original developer is no longer at the company, and yet I can
find the information in a ticket. Our Jira installation is more like a shared
brain than a PM tool.

------
cheriot
> So why do companies use a tool that works for a few PMs and business leaders
> when dozens or hundreds of engineers hate it?

In fact, Jira is so infinitely configurable it reflects the org chart and
culture of the company using it. Most Jira complaints I hear are more about
that person's company than the tool. That said, the tool definitely doesn't
help as much as it should (largely because engineers don't make purchase
decisions).

------
rado
Never understood the Jira hate. It's very useful and infinitely better than
email.

------
mixmastamyk
Well, I've been forced to use Jira for a decade or two now. Not a huge fan,
but it is ok. Ties directly into gitlab, has a kanban-like board. Every used
bugzilla?

But, I've never had any of these other complaints. When will this ticket get
fixed? By the end of the sprint. I do tickets in order of priority. Rarely
been a problem, so surprised to hear it brought up.

At my current gig, the PM has been there a decade and I only a year, so a
great majority of the time I am asking/he is telling me how things should work
at a high level. I value the advice.

I did work for one disaster project about ten years ago. Constantly
interrupted for fires, tens of hours of meetings per week, and rarely finished
sprints. We were overloaded on tickets because sprint planning never took
interruptions/meetings/bugfixes into account. We used bugzilla there, but it
wasn't the culprit.

Annoyances: just thought of one. The issue page has a ton of stuff I don't
care about and de-emphasizes the comments which I'm most focused on. I also
don't like how when you click on things it switches to edit mode.

------
Simulacra
Jira lost its usefulness around 2014. It became much too cumbersome to use,
and Atlassian‘s help documentation was/is? out of date. We asked for training,
something more than poorly written documentation, and we were quoted an
exorbitant price for that training. That was the straw that broke the back and
we left Atlassian for good in late 2015 and never looked back.

------
idj
While you do have some valid points, especially when it comes to friction
between PM/Devs, the way you seem to be using Jira seems to be the polar
opposite of what I have experienced.

Granted, I don't have an overwhelming amount of experience working at
different companies, but I feel like the Devs in my company were actually the
ones that wanted to use Jira for customization options.

Intriguing!

------
tlarkworthy
I like jira. Our installation is pretty fast and I need something to track
what is outstanding. The query interface is quite powerful, and I can use it
to gather evidence that something needs more attention. It's got too many
fields but you can turn these off, unfortunately for my org that requires IT
so I live with its current configuration.

------
natchy
> Jira was made with project managers and product managers in mind

A step further, SCRUM was made for product managers in mind. Engineer-centric
Agile methodologies like Extreme Programming are missing from SCRUM
guidelines.

Most product management methodologies have a _bring-your-own-engineering-
practices_ philosophy, which means they were created in a vacuum.

------
CraigJPerry
JIRA is just a tool. A pretty reasonable one. It integrates with every dev
tool under the sun at this point. It’s as lightweight, or invasive, as you
want it to be.

Sometimes there’s people or workflow problems that get blasted as jira (or
rally/ac) problems because that’s the interface you see those people or
workflow problems through.

~~~
AstralStorm
Nah, generally the point 1 stands. JIRA has potent top down customization
tools that are easy to misuse, e.g. adding required fields, task types
priorities or defining task flow.

Just that information overload can make working with it a real pain.

These can easily break its own features e.g. scrum or kanban boards or
backlogs, which are configured separately.

And the dev or project lead typically does not have access to directly
customize it, because JIRA ACLs are way too broad or company has a top down
policy on it.

On top of that, it has rather weak support for default values...

Email notifications are also not exactly customizable by the user. It's worse
at that front than bugzilla even.

One thing that was sort of customizable are the frontend report views. Shows
for whom the app is made - beancounters.

------
atonse
Every single project I've been on in the past 15 years (public/private sector,
many verticals, different companies), when push comes to shove, people resort
to tracking everything on simple spreadsheets or punch lists. And it works
just fine (although this results in more communication which is anyway true
when things go wrong or overdue, regardless of tools).

So I'm really wondering how much utility a lot of these tools bring (I LOVED
Jira in 2006 when it was a glorified table with powerful filters, but I was
using it roughly like a smart spreadsheet). I feel a lot of what they add is
just busy work that you have the luxury to play with in normal times, but when
you don't have the luxury to do busy work, it just slows you down without much
benefit.

What have other people's experiences been? An emergency can be a great filter
to show you what matters and what doesn't.

------
anuragojha
There is perfectly common sense solution to every issue OP has raised. I have
used JIRA for 7 years in many different teams and I think it works and does
not get in my way as a developer. In my experience the people who seem to have
trouble with JIRA are the same people who have trouble with basic software
engineering processes and being organized.

"Bosses (managers) get stuff done through meetings – changing tasks every 60
minutes." \-- I don't know what bosses you are or have worked with but
incompetent leadership and poor software engineering acumen can't be solved
with buying software subscriptions.

Why are you trying to make for the tool being bad when the blame lies with
people? I am tired with hearing this bogus notion of friction between Bosses,
PM, Engineers and somehow you can pay your way out of lack of alignment in an
organization.

------
riskymagemerge
Shots fired! It's true though. Using Jira is a struggle.

~~~
jeff_vader
I started tolerating it after discovering it has keyboard shortcuts. Try
pressing <shift>+? to see what's available in given context.

\+ Make sure you have it bookmarked as search engine. Also makes it so much
nicer when you can jump to specific ticket by using 'j FOO-123' from address
bar. Or 'j whatever keywords' to do regular search.

~~~
spupy
I like the dot shortcut - press “.” and start typing a command.

------
rundmc
Having been away from development tools for fintechs for a while I went back
to my trusted Jira tool to find it incomprehensible. I also tried & quickly
hated Teams & even current Slack. My new go-to tool that anyone in our org or
from partners can use immediately is AirSend.io.

------
wins32767
The attitude embodied in this is unfortunately common. Delivering a successful
product is a lot more than just writing code and shipping features. Planning
so that you can launch your marketing efforts, ensuring you have a team ready
to support whatever you just shipped, or making sure you don't sign new deals
that result in 6 months of work needing to get delivered in the next 2 months
are all just as important to the business as the day to day work the
developers do. Sometimes being a team player means you are a less effective so
that other people are more effective. Jira isn't a perfect tool, but the case
would be better made by someone who isn't myopically focused on optimizing a
subset of the whole product delivery process.

------
tus88
Yes. I remember the first time I encountered Jira, I assumed we would just
login and start created cards and tasks etc.

Except the first meeting we were introduced to a "consultant" who needed to
"design" our process flow before we could do anything.

I went back to Trac needless to say.

~~~
hinkley
I think the problem is that Atlassian has designed their tools for information
hiding.

I may not agree with Larry Wall on much, but he is credited with one of my
favorite aphorisms:

Easy things should be easy, and hard things should be possible.

You can't pre-filter complexity for developers. _That 's our job_. We have to
know that there features available even if they have been turned off.
Otherwise we're going to blame the tool for skimping on functionality. And we
are perfectly right too, because how the fuck are we supposed to know that
Bamboo has a feature if the button only shows up for full administrators?

Of course we're going to bag on it. And they deserve every bit of it.

------
ch4s3
I'm definitely feeling this today. I'm effectively locked out of jira today
because the new versions of Chrome and FF block cookies that are
"SameSite=None" without "Secure", and all of Jira's cookies appear to have
this problem.

------
johnnyfaehell
I think the post hit the nail on the head with the question paraphrasing „Why
do companies buy project management software that only project managers love
But engineers hate?“ The answer is project managers manage projects so need
project management software.

------
johnnylabu
My company uses Jira as our primary tool for development and we really like
it’s simplicity and effectiveness. With integration with Bitbucket, Trello and
Pipeline our developers find it easy to work with. Jira is also easy for non-
technical team.

------
hddherman
The JS-heavy web interface of Jira can be infuriatingly slow, so perhaps the
frustrations start from there.

Jira, the project management tool, can actually be great, if you configure it
properly. The issue lifecycles, what fields are visible, how the board is
showing things etc. can be designed to be as simple or as complex as you want
it to be. In addition to that, the integration with Bitbucket and Confluence
is also fantastic for referencing issues and features across the code and
documentation.

Misuse of a tool does not make it a bad tool.

Disclaimer: have worked on developing a Jira plugin, so my understanding of
Jira might be a bit more advanced than that of a novice user (but not by
much).

~~~
WorldMaker
> if you configure it properly

This gets into the heart of what I consider to be the biggest issue with Jira,
especially compared to nearly every other option, and was disappointed this
article wasn't about: Jira is almost a poster child for the "inner-platform
effect" [1]. Jira isn't so much an "issue tracker" as it is an "issue tracker
development environment", with an ugly PM-focused configuration DSL GUI
instead of a more useful to developers script language.

Presumably most of Jira's other technical faults derive from there. It's
incredibly slow to use, which is about what you would expect of any program
suffering from the inner-platform effect. It presumably has to check layers
and layers of "configuration data" to do even the simplest tasks. It's easy to
assume the databaase backing Jira isn't well normalized or index-optimized,
because you can't build "configurable" normalization. (You might get away with
profile-based dynamic indexes, but even then that will only get you so far,
especially if your tables are key/value soup where traditional relational DBs
fall down at indexing.)

Which gets back to the process failures that the article does talk about
because it's easy to suffer from something like the inner-platform effect when
your target audience (PMs) don't know what they want until they see it (if
they ever figure it out), in part because of the impedance mismatch in the
decision<=>development status flow between PMs and devs. So I would say the
"inner-platform effect" is both a symptom, a cause, and an exacerbater of
those process issues.

(Though I suppose it would be tough for an article directly pitching a Jira
add-on to be too critical of Jira's underlying technical problems.)

[1] [https://en.wikipedia.org/wiki/Inner-
platform_effect](https://en.wikipedia.org/wiki/Inner-platform_effect)

------
linknfg182
Sorry everyone on the bot. Just yelled at our marketing people to turn it off.

------
c3534l
I personally found the main criticisms to be insightful reasons why Jira
doesn't really add much value to a workflow, but most problems can be dealt
with by taking those issues into account and continuing to use Jira. Then
again, I'm not entirely convinced tools like Jira are ultimately much better
than just managing with email and whiteboarding, which is probably why I feel
so meh about it. Everything it does just feels unnecessary 99% of the time.

------
necco908
I feel like half of my bosses don't understand what goes in to my teams
process for new features. They're probably the ones that bought Jira in the
first place.

------
flarg
Jira totally removes the fluidity in the software development process, I've
stopped using it altogether and now rely on Google Docs and Sheets.

------
amai
The problem with Jira is that a lot of useful features are only available as
plugins. But your company won't pay for any of these plugins, or they simply
don't want to maintain and install them for security reasons.

So you are stuck with the basic Jira version you company pays for and will
never see any of the nice extensions that are available for it.

------
Animats
That site is annoying. Popups. Fake "notifications".

As a bug tracker, JIRA seems to be OK. As a development system, not clear.

~~~
riskymagemerge
Sorry! We know the bot sucks and we just turned it off. Lame marketing people.

------
nine_k
Jira does have an extensive and documented API. They have e.g. an official
integration / "client" for VSCode. There is a couple of CLI tools.

I hope more alternative frontends will eventually come up to address the UI
issues, to streamline particular kinds of usage, etc.

This can't address the API speed, though.

------
skynetv2
You dont appreciate Jira till you no longer have Jira.

~~~
AstralStorm
Depends. I worked using Fogbugz and Trello on different projects and it was a
blast in comparison. And another unnamed homebrew which had warts but was
still better than overloaded JIRA in some other projects.

Then again I've worked on the project where the source of truth was a set of
Excel documents shadowing 5 different ticket systems. Very briefly.

That said if you're lucky, JIRA can be set up to work relatively well.
Especially if you keep it simple.

------
uchman
I've noticed that more people complain intensely about stuff that's not going
away - Jira, Spreadsheets, Twitter...

------
awinter-py
yeah, there are a couple of up-and-coming tools that try to correlate product
spec to tickets while maintaining a separation between the two

hard problems like spec, estimation of work, and assignment of work to people
are conflated in a ticketing-only universe

~~~
rgbrgb
Interesting. Can you drop some links to your favorites?

~~~
awinter-py
haven't used any so wouldn't endorse, but the general category is 'roadmap'
tools or what used to be called 'idea management'

there are some 'release management' or 'launch management' plugins for JIRA
that address the other side of the pipeline, but solve similar problems --
also haven't used, but friends who are big-company PMs talk about them

IMO many saas products are inflexible, their strength ('we automate
workflows') is also a weakness ('better not deviate from these workflows')

The only project management tool I've heard people rave about is airtable,
which is basically an improved spreadsheet UX and not purpose-built for
project management.

I suspect the future of project management saas is tools / plugins that
provide summary views, but the tickets / specs exist in freeform spreadsheets
like airtable. This 'view plugin' ecosystem is alread starting to exist for
notion and roam.

------
glouwbug
I wonder if JIRA uses JIRA to track itself

~~~
eddieh
It does
[https://jira.atlassian.com/projects/JSWCLOUD/issues/JSWCLOUD...](https://jira.atlassian.com/projects/JSWCLOUD/issues/JSWCLOUD-20463?filter=allopenissues)

~~~
seanjregan
I can confirm we do.

------
jhaddow
Just use Basecamp

