
Death to JIRA - kNawade
https://techcrunch.com/2016/12/11/death-to-jira/?ncid=rss
======
currywurst
From the article:

> _I stress that it’s not specifically JIRA itself which is guilty of this.
> All of the above is implicit in the notion of reducing software architecture
> and development to a set of “tickets.” JIRA’s great sin is only that of
> being the most successful and widespread ticketing system. The notion of
> specifying a software project with a set of tickets is itself the enemy._

Hope that saves ppl from this terrible clickbait

------
minimaxir
> And so JIRA ticketing subtly but powerfully tends to push developers to work
> on one ticket at a time, instead, which is often both less efficient and
> more prone to drastic late-in-the-game failure.

Technical debt is measured in net present value.

As a QA engineer myself, it is more valuable to explicitly account for _when
and why_ a given software change is made then it is to rush things out,
because when a later change inevitably breaks an older one, the engineer can
immediately know _when and why_ it happened, and what to fix.

Relying _solely_ on design documents means that if something goes wrong in a
sufficiently complex system, it can take a very long time to isolate and fix
the issue. (no, TDD does not alleviate this)

------
crazygringo
> _I promised a better way... a well-written 8-page document can define the
> nuances of a complicated system far better than a whole cumbersome flotilla
> of interlinked JIRA tickets._

I'm mystified... everywhere I've ever worked used design documents to _some_
extent -- not for simple features, but more for things that are truly
"complicated systems" with nuances.

Are there really places that attempt to do project _design_ solely with
tickets? I almost can't believe it.

(Although in terms of effort estimation, breaking the design doc down
afterwards into tickets, and then estimating those individually, is a very
useful exercise -- a design doc describes the _outcome_ , the tickets describe
how to _get there_ , which is what you're really estimating.)

~~~
fiftyacorn
Its a recent trend to skip the documentation and have a sparsely documented
JIRA in the belief it encourages agile development. I just groan when i see it

~~~
tetraodonpuffer
there is also the "let's define everything by user stories" way of doing
things (as if having a bunch of stories in whatever agile tool is better than
a proper functional spec / design spec)

------
yoz-y
For me, JIRA is addressing a fundamentally difficult problem: how to separate
work on a monolith between several people. At some point the separation into
tickets, tasks, requirements or whatever one wants to call them is necessary.

------
firewalkwithme
JIRA is a fantastic tool if management know how to use it, and how to limit
themselves. Having used 2 other horrible alternatives I really miss JIRA

~~~
kaspiCZ
In case it might help you:

For projects where there's possibly only a dev or two and the project/client,
we had success with producteev. It's much less complicated than e.g. JIRA.

If you set up rules for tags and priorities you can manage delivery quite well
with it.

Highest priority is reserved for blockers.

Sample of our tags: affects customer, bug, feature, change, production,
technical debt

------
alkonaut
Every large scale software system needs a ticket system if _some_ kind. You
might separate the backlog from the bug reports, or omit one part, but you'll
have _something_.

You can't find the reason for a change otherwise, you can't find all the
related changes for the feature, you can't catalog incoming bugs and answer
whether the last bug report must be tackled or has already been fixed and so
on.

This is why - like it or not - there always _is_ an issue management system.
It's on a server somewhere, or in an excel sheet, or emails, or on a piece of
paper. But it's there.

The usual criticism of Jira is that it's heavyweight compared to e.g GitHubs
issue tracker, or whatever post-it moving system is the latest fad.

A fair criticism of Jira is that it makes it too easy for management to encode
and expand the formal rules for e.g task workflows, and that these rules
invariably end up being too rigid.

An organization should have the least invasive workflow it can, but it should
encode and enforce the workflow.

In the end, just like you always have an issue management system, you also
have a change workflow. Either it's encoded formally using an issue/PR system
or it's ad-hoc via chat and email (which scales very well up to around 2
developers but shows it's weaknesses already at around 3)

~~~
prodigal_erik
That's the main failure mode I've seen. An over-engineered and role-limited
workflow in which the real-life state of the project is considered invalid or
nobody is authorized to express it.

------
Suresh_MacApp
Hackers, Very Well written article, we have been facing this pain point and we
went on to create a wonderful system which handles everything for a project in
a simple intutive way. I have shared the screenshot here for the hackers. Lot
of positive feedback, looking forward to hear your sincere comments and take
it forward.

[https://pbs.twimg.com/media/CzeajADUUAE87oa.jpg](https://pbs.twimg.com/media/CzeajADUUAE87oa.jpg)

------
LKAndrew
The author clearly doesn't have the experience in agile development necessary
to be commenting on this. As a software engineer turned scrum master, I can
say that my company is a well oiled machine using JIRA and agile methodologies
perfectly well. My engineers don't have these complaints. Clearly he's doing
it wrong.

------
cthulhujr
It seems like most organizations that use JIRA start off with good intentions,
but it eventually devolves into a huge mess that users dread. Maybe it's
because the system tries to do too much or, more likely, it's a user problem
and orgs demand more and more features. Whatever the cause, it's leading to a
death by 1000 cuts.

------
metamicah
YMMV but one method I like to mitigate the issue the article talks about is
keeping documentation in source control, and requiring a change to
documentation (or explanation why there should be no documentation change) in
association with the resolution of a JIRA ticket.

------
bitherd
tl;dr Blame the tools.

~~~
mgiannopoulos
Amen. It's always the people. The people are the system, not the tool.

