
JIRA is an antipattern - panarky
https://techcrunch.com/2018/12/09/jira-is-an-antipattern/
======
perlgeek
> And so people take tickets, implement them as written, pass them off to
> whoever is next in the workflow, consider their job well done, even if
> working on scattered groups of them in parallel might be much more effective
> … and without ever considering the larger goal. “Implement the Upload
> button” says the ticket; so that is all that is done. The ticket does not
> explain that the larger goal of the Upload button is to let users back up
> their work.

Jira was designed for agile software development like Scrum, so you should
write user stories, not mini specifications.

An upload button alone is no user story, a story might be "As a user, I want
to be able to import the Excel reports that I get from company $XY, so that I
don't have to manually enter the data, and save a lot of time that way",
ideally including a reason why that data needs to be there.

That way, you get the context that the article is bemoaning the lack of, and
the developer might even think "Hey, I know company $XY has an API for getting
the report data, wouldn't it be even easier if we fetched it directly?"

And in a good agile process, you'd discuss this with the product owner, and
rewrite the story to "As a user, I want data from $XY company in my system
with minimal effort" or something like that.

No tool can substitute a good development process, and good communication
between the involved parties.

That said, Jira does have it downsides, and not tracking dependencies very
well is one of them.

And then there are things that can be downsides, but don't need to be. It's so
flexible that many shops configure it to be pretty much unusable, but others
create workflows that work very well.

~~~
lumost
I think you've hit on the fundamental contradiction of agile and scrum.

> An upload button alone is no user story, a story might be "As a user, I want
> to be able to import the Excel reports that I get from company $XY, so that
> I don't have to manually enter the data, and save a lot of time that way",
> ideally including a reason why that data needs to be there.

The implementation of this functionality in a way that will delight customers
could hypothetically take 3 weeks as it requires the implementation of an
upload button, a datastore to store the uploaded values, and an integration
into a legacy feeds system to get the spreadsheet's data to all of the places
it needs to go.

In most scrum processes 3 weeks of effort would not be accepted, and the story
would be "broken down" into smaller issues such as "implement an upload
button". Even worse scrum projects emphasize anti-patterns of "parallelizing"
efforts, so we'll assign each of those smaller stories to separate
individuals. While theoretically a customer focused engineer could look at the
original user story, there is minimal incentive to do this - and most
engineers will focus on pushing stories across the board, the upload button
may or may not ever work in a way that customer's desired - and any attempt to
fix it requires restarting the whole process.

~~~
perlgeek
> In most scrum processes 3 weeks of effort would not be accepted, and the
> story would be "broken down" into smaller issues such as "implement an
> upload button".

Yes, but a good scrum process goes like this:

1) the PO presents the story

2) the developers discuss it, and find that it doesn't fit into a single
sprint

3) developers and PO together break it down into small issues, for example by
turn the original story into an epic, and creating more, smaller issues in
that epic.

So when a developer works on the smaller story, they have heard about the
context before, and have a link to the epic with the broader context in case
they have forgotten.

It's not automatically provided by Jira, but if you use the tools correctly,
you can absolutely provide that context.

~~~
renox
Bah this process is faulty, we use it at work and this means that a feature
which has to manage N things is almost always split into 'manage 1 thing' then
'goes from 1 to N' even though it takes more work and the resulting code is
much more ugly..

~~~
jeffreygoesto
If your problem's complexity is big enough, you can't get good solutions
without an explicit architecture step. I've seen quite a few bad ad-hoc
architectures being created trying to break down epics that were too big. Your
team needs a lot of discipline to come up with a good plan/architecture (per
story/epic at least) first. Scrum did not help here, to me it seems it
legalized hacking away the day... In some domains you can't pay back that kind
of dept easily...

The article may have a clickbait headline, but „have an overview and use JIRA
in addition to track the leafs of the work hierarchy“ is true.

What I found is that almost all projects try to organize as tree but they
should organize as matrix, at least if there are many cross-cutting
components.

~~~
hinkley
If my team had that much discipline to begin with, they’d do just fine without
Scrum.

------
hn_throwaway_99
I expected to read this as a "Ah yes, another JIRA bashing article." I've
tended to view JIRA as "the worst of all project tracking tools, except for
all the other ones" so I like to rise to its defense when I see folks
complaining about it without taking into consideration the needs of other
stakeholders.

That said, I've found myself agreeing with pretty much everything in this
article. While I believe that JIRA (if properly configured) can serve as a
good issue tracking system, attempts to do top-down, high level planning on it
have always left me with nothing but frustration. My advice would be to
completely ignore any of these features (e.g. all the "portfolio" add-ons), do
high-level planning down to the epic-level in something else like Excel, and
then map that to tickets in JIRA. The "Nirvana" of having complete visibility
from very high, enterprise executive level planning down to the "what am I as
an individual developer working on today" level in one tool is a false idol
and just not possible.

~~~
sb8244
Asking seriously: is it that it's not possible with today's tools, or
philosophically not possible?

~~~
throwaway9471
My manager had a rule, that each member of the team was only allowed to have
one unresolved ticket at the end of day.

We had a weekly meeting where we would be badgered about every >1 unresolved
ticket and had to come up with an action plan to make sure it never happened
again.

So coincidentally, we would "forget" to create a ticket for every issue, that
would take more than a day, until it was one day from completion.

~~~
praptak
I do sometimes follow this rule. Caveat: it requires unassigninig tickets that
I'm not actually working on.

It makes some people cringe in horror but once you start doing that it does
wonders.

~~~
Wowfunhappy
Is the idea behind this "I can only focus on one thing at once, so unassigning
myself allows someone else to take up the task in the intirim", or something
else?

~~~
praptak
Mostly this. Obviously, this assumes shared understanding of assignments as
"things I'm working on" rather than "queue of things and also commitment do to
everything".

Combining the original "one open ticket" rule with the second approach is
rather bad. That's why I hope it was used in the context of the first
approach.

------
KaiserPro
_sigh_

The author uses a flawed analogy to push a flawed argument.

Jira is a tool to track what _stuff_ needs to be done. Using the author's city
analogy, they appear to be advocating that all city workers need to have a
vision of the whole city plan for any task they they are doing, that doesn't
scale.

Large projects are to big to fit all the detail in one person's head. Design
goals are broken up, issued to specialist teams, which then break them up
again.

To then blame the tool for worker not bothering to understand what they are
working on is not the fault of the tool, its the fault of the worker.

 _Ok smart arse, how do _you_ use Jira then?_

Simple, its a big arsed multidimensional to-do list. There are a set of
business goals with solid business deliverables(which of course translates
into vague tech targets) Each team is assigned high level tasks. Its up to
them to split them up and write down _what_ they want to do, and then in small
subtasks _how_ they are doing it.

if they are too stupid to ask "how does this align the business need?" then
they shouldn't be allowed grown-up scissors. (why are you hiring them?)

~~~
steve_taylor
> Using the author's city analogy, they appear to be advocating that all city
> workers need to have a vision of the whole city plan for any task they they
> are doing, that doesn't scale.

For most projects, it does scale. The problem with almost all software
development analogies is that they attempt to draw parallels between design
and manufacturing. Software development is much more design than
manufacturing.

A more suitable analogy would be art. Imagine a group of artists commissioned
to create a painting. The designers decide, upfront, the main elements of the
painting, then someone else breaks the work down into tickets based on those
elements.

Unless extremely well managed, the result is likely to be hideous and the
project is likely to have a high turnover of artists. This is pretty much what
happens in most software projects. The real problem, as this article
identified, is that a bigger picture perspective is needed. Unless a project
is crystal clear about the big picture, everyone will have their own big
picture and build features accordingly.

~~~
TeMPOraL
> _The problem with almost all software development analogies is that they
> attempt to draw parallels between design and manufacturing. Software
> development is much more design than manufacturing._

Also construction.

The way I see it, what programmers do is not constructing a building, they're
doing the architecture (and wiring plans, and landscape plans). _Construction
is what compilers do_.

------
ilaksh
I agree with the issues raised by the article but disagree with the
conclusion. Prose is great but the way he suggested creating an architectural
doc up front doesnt sound like it can evolve as the trench warfare progresses.

I feel like a big part of the issue is the disconnect between management and
development people in many ways. Most managers only really care about the
surface level of the software. Their situation of not being able to directly
control the guts and the fact that their boss only sees the surface level
reinforces that.

Another issue is that management expectations are almost always unrealistic.
It's the nature of software development because it is a research process where
it's exponentially easier to envision the next step than it is to implement
it.

My current belief is that both project managers and even executives need to be
forced to look at at least some code every now and again and included in
software engineering meetings routinely. That is the only way they will start
to understand the scope of the work and realize that there is work under the
surface.

~~~
grogenaut
I use architecture docs constantly at work as a way to scale myself. I can get
a decent first cut 4-8 page doc with problem summary, rationale,
implementation (usually api and some schemas), interaction diagram,
alternatives considered done in a 4-6 real world hours now. This is for a 1-3
engineer month sized project. I also find I can get a 3 page one done with
less details on schema and api in about 1-2 hours.

I find that being able to do this allows me to scale myself a ton. I can take
a discussion I had with other engineers in a design session, or my thoughts on
an implementation, written up quickly. I can then take these docs and send
them around and have a concrete place for everyone to start discussion.

I find even if my idea is not what others are thinking, it greatly helps them
articulate the delta and why. The opposite is everyone sits in a meeting and
argues for their point of view in parallel while they do the design on their
idea in parallel, which causes more fighting.

So to me the cost of an arch doc is not very high anymore, and the
effectiveness is very high. I can send that doc to 30+ people and not have to
have the same 1-2 hour conversation over and over. However it took me quite a
while to be able to get my thoughts onto paper that fast.

I also find the 1-3 page writeups help me sell managers on spending the time
on the longer doc either for me or their team.

The other thing that has been great for me is that I can write up distracting
ideas (I have bad shiny object syndrome), quickly, and get them to my peer
manager. This means I can go back to my current work without worry about it
being forgotten about. Usually I get feedback in a day or so from the manager
on how good the idea is and where it fits priority wise. This allows me to
innovate and implement at the same time.

~~~
scruple
It's very interesting to read this. I've come around to the exact same ideas,
with the same perspective, and for the same reasons you've listed here. I've
also had the same experience. These docs are critical for my team at this
point. Without them, we'd go back to languishing for any number of weeks while
we grapple to understand the larger context. All of that said, it takes me at
least 2x longer to get these documents created. It's easily a 1-2 day affair
for me. I'm also on a small team, with only 4 engineers, and the projects we
work on tend to run 1-3 months. I wonder if this process scales to larger
teams and projects.

~~~
grogenaut
It used to take me that long. For more detailed docs it still does. I'm also
way slower when it comes to business justification and executive team
arguments but getting better. Practice makes perfect though. 5 years ago it
would take me multiple months to write such a doc and I'd get bored
constantly. Now I'm much faster. Some of my mentors can do these things on the
fly in a meeting and drive consensus easily on stuff they have 0 context on.

I also got better because I had a manager who suggested that I just start
writing these things up for a few hours each week. Just like authors who say
that you have to write to get better at it, and how you write essays in high
school and college even for arguments you don't believe in.

As for scale the process, yes it seems to. We try to review anything that's 3
months engineer time or more with a Sr. engineer from another team. Wider for
larger projects. Bring in Principals when you have real quandaries.

The trade off is really writing time to communication effectiveness. If you
find yourself having the same slack discussion more than 2x, maybe it should
be in a document.

------
lmm
Wow. I hate JIRA but this article gets it completely backwards. Having small-
scale tickets that you actually _finish_ is the very essence of agile -
limiting work in progress, defining "what done looks like" in a customer-
facing way for tasks that each last at most two weeks. Ignoring the "wider
vision" is the best way to produce software that actually solves people's
problems instead of beautiful n-tier architecture that doesn't do anything
anyone wanted.

JIRA is heavy and slow - it's model of limited transitions is fundamentally
flawed, encouraging micromanagement and making mistakes hard to undo. But a
lightweight board that you push tickets through - the famous "kanban" \- is a
great way to develop software (I've had a lot of success with Trello, though I
fear it's only a matter of time before Atlassian bloats it into JIRAness).

~~~
geocar
> Having small-scale tickets that you actually finish is the very essence of
> agile

Bollocks.

The "highest priority is to satisfy the customer through early and continuous
delivery of valuable software."

Not tickets, small or otherwise. Not _tasks_. It has nothing to do with two-
weeks.

> Ignoring the "wider vision" is the best way to produce software that
> actually solves people's problems

I have no idea what you could possibly mean by this.

Every time I've ever seen a _modular_ development that isolates developers
from the business (or from each other), I've seen brittle software, and that's
assuming they get done at all.

> But a lightweight board that you push tickets through - the famous "kanban"
> \- is a great way to develop software (I've had a lot of success with
> Trello, though I fear it's only a matter of time before Atlassian bloats it
> into JIRAness).

Listen, if software helps you, then great, but if your whole life is "pushing
tickets", you're not doing Agile. It doesn't matter if you're using Jira or
Jello.

[https://agilemanifesto.org/principles.html](https://agilemanifesto.org/principles.html)

~~~
Klinky
The problem with Agile is that no one is doing True Agile™, because no one can
agree on what True Agile™ is.

~~~
joejerryronnie
Do not try to do True Agile, only try to realize the truth. There is no True
Agile.

To me, Agile is really a set of principles to help you decide what to focus on
(e.g people over processes). The different methodologies (scrum, kanban, etc)
are just frameworks to help you build the best dev process for your team while
trying to keep the agile principles front and center.

In reality, all kinds of factors get in the way of True Agile - experience of
devs, team dynamics, company incentive structure, management expectations,
management’s management expectations, how the company handles failure and the
subsequent ownership vs finger pointing, etc. The actual implementation of
Agile should be different for each organization because the environment in
which they operate in is different. With that said, there are certain core
principles and practices that are very beneficial across the board and
consistency across teams within an organization certainly helps.

------
solatic
Yay, another Jira bashing article that completely misunderstands Jira.

Jira actually does a better job of helping bottom-level workers see the big
picture than any other tool in its class, because every issue can be linked to
any other issue, not just the Epic that the issue belongs to in the hierarchy
but issues in completely separate projects belonging to completely separate
teams. It's quite easy and supported in Jira to link bug issues to the
customer support issues where customers describe, in their own words, what
triggered the bug for them. Jira issues also support rich text in the default
Description field to write the prose that the author so desperately wants.

Jira is just a tool. If your organization is broken, then Jira won't fix your
organization. If people in your organization don't buy in, then the tool won't
help them. The comments field that helps people see exactly all of the updates
regarding any piece of work - whether that is a small piece of work on the
bottom or an Epic - is completely worthless if people still email everybody
else. The Assignee field is completely worthless if your organization never
assigns issues to people, and it's even more worthless if your organization
wants multiple people to be responsible for an issue, which is an
organizational antipattern. If you host Jira on-prem and don't give it enough
resources, or do stupid shit like putting the Lucene indexes on networked
storage (if I had a dime for every enterprise infrastructure team which only
offered a single class of networked storage...), then you will have a Bad
Time.

It's a controversial tool because it's Conway's Law made visceral. If your
organization is dysfunctional then your Jira instance will be dysfunctional.
If your organization Gets Shit Done™ then Jira will help you organise and get
even more shit done. I'm not sure it's fair to criticize Atlassian for failing
to fix the majority of dysfunctional organizations out there.

~~~
whorleater
>I'm not sure it's fair to criticize Atlassian for failing to fix the majority
of dysfunctional organizations out there.

when JIRA is marketed by Atlassian as the tool that will make your
dysfunctional organization functional, then yes, it definitely is fair

~~~
Jedi72
In the land of bullshit advertising which we all live, Atlassian are the least
guilty of being immoral.

~~~
sedatk
We can blame multiple companies for bad advertising at the same time. There is
no priority queue there.

------
CoolGuySteve
Apple has a system called Radar that treats everything like a ticket. Projects
are tracked completely from Radar.

Considering Apple manages to ship pretty decent software, I don't think
blaming your tools is really appropriate.

The only real difference from Jira was that despite coming from the Carbon era
of design, Radar was much nicer to use because, as a native application, it
showed tickets in a regular table view where you could multi-select, drag and
drop, etc. I personally find Jira miles more confusing than Radar after having
used both extensively.

But that's a fairly minor difference, the design paradigm was the same.

~~~
Cymen
There have been at least a couple of posts here that had thread discussion
about this approach at Apple leading the focus to be on features over bugs.
That things don't get fixed. Before holding Apple up as an example of good,
best to look into those as those complaints/comments here mirror things I've
seen on other venues in terms of features versus working software being
shipped by Apple.

~~~
briandear
That emphasis on features over bugs is a myth. Look at almost any Apple
developer’s assigned Radars and they’re mostly bugs. Pay attention to Craig
Federighi’s initiatives and stability, security and bug fixes have taken a
top-priority at least over the past year or so. Look at iOS 12 and Mojave for
public examples of this focus. People complained that iOS 12 didn’t have a lot
of new features, but it’s almost universally acclaimed as far more stable and
performant than iOS 11. Same for Mojave. Compare that to the release of Sierra
for example.

~~~
zapzupnz
That could just come down to Apple's cycle. They tend to do one release with a
lot of features, then one release for stability. The precedent was set with
Leopard and then Snow Leopard, repeated with Lion and Mountain Lion, and so
on.

------
rsyring
This article makes some really good points about the importance of knowing the
larger project and infrastructure context when digging into details of a
software project to fix bugs or add features.

And, I'm not a fan of Jira.

But, the difficulties noted in the article feel wrongly assigned to Jira. They
aren't Jira's fault. It's a process problem of the org using Jira. A
deficiency in the way projects are architected, documented, and communicated
about. It's not the tool itself that is the problem.

~~~
erikpukinskis
You’re mistaken that there is a single attribution to “the problem”.

Tools and process work together to create a production system. When the system
fails both share blame.

------
afpx
The comments here are funny. Iterative-incremental software processes have
been around for 40 years or more. I’ve been developing software for 25 years,
and I’ve never seem anyone use “waterfall”. As far as I know, it hasn’t been
widely used since the 50s. Scrum was a way to “dumb down” software processes
for neophytes. But, it doesn’t guarantee success. No specific process can
guarantee success; it always comes down to the quality of the engineering
staff. And, if your engineering staff is skilled and experienced, they won’t
need a defined process anyway. JIRA is just a system to track deadlines and
deliverables.

“Processess” are things contrived by consultants to be able to sell tickets to
expensive conferences.

------
mjpuser
JIRA is meant to break up work. Atlassian has another product called
confluence to let you write prose, like the author wants, and you can link all
these things together. When you have a group of 3 people on your team, you
need to coordinate different parts of the feature into separate tasks for each
developer so that they can work in parallel. This guy/girl hasn't discovered
anything we don't already know.

------
BjoernKW
Jira is an incredibly flexible business process tool that - among other areas
- lends itself particularly well to software development processes in larger
organisations.

With all the criticism levelled against it I have yet to see a better tool of
this kind.

Jira isn’t opinionated about the process that’s implemented with it. If you
want that there are alternatives such as Basecamp for instance. If you want
something simple there’s always GitHub Issues (or similar tools).

If you need something customised then other than building a tool yourself Jira
likely is your best alternative (unless you want to manage your process with
Excel sheets, that is ...).

If, on the other hand, your process is broken and built around anti-patterns
then yes, Jira will absolutely help with fostering and perpetuating those but
it’s really not the tool that’s to blame in that case.

~~~
vassilyk
At last a comment mentioning alternatives.

Jira is the primary target of the article when it probably should be how
people run agile projects, and how organizations tend to struggle findind the
most efficient (software development) processes to reach their business goals.

This article could have been written for any similar Jira direct / indirect
competitors like you mentioned, and the like of Asana, Trello (Atlassian),
Aha, plain old Word, Excel and so many others.

But it wasn't, because it's just easier to pick the elephant in the room and
have a go at what remains a great tool when used wisely. Kind of like pen and
paper, after all.

------
sixdimensional
I know that there was a backlash against it, but sometimes I find the
simplicity of the Agile Manifesto to still be a good reminder not to get
carried away with a highly specific way of doing things. There needs to be a
balance.

"Individuals and interactions over processes and tools...

...That is, while there is value in the items on the right, we value the items
on the left more." [1]

In this case, highlighting all the discussion about JIRA vs. what you actually
do / what works for you / your team / product / organization.

[1] [https://agilemanifesto.org/](https://agilemanifesto.org/)

~~~
EdCoffey
Yep. Jira isn't an antipattern; inverting the first value of the agile
manifesto is an antipattern, whether you do it for Jira or any other tool (or
process).

------
kovrik
In my experience, the problem is always in people, not tools.

Nowadays, Agile/Scrum is a buzz word, every company is trying to get it, but
rare people understand it. They buy tools (like JIRA), they do standups, they
assign story points...and then things become messy and it all turns into into
a glorified waterfally kanban with story points.

JIRA is just a tool (bloated, maybe), nothing wrong with it. Personally, I
find it to be OK -- no major complaints about it.

~~~
lugg
I did a planning meeting while working remotely.

The only thing that came out of it was a big word document that looked like
the big word docs id write for waterfall back in the day.

I don't think people realise just how little things like JIRA and Trello do
for you.

The only thing they can give you is a different view of that same word
document.

The second they over clutter themselves with junk in the interface and custom
flows the benefit to using them is lost.

Trello is a good example, it used to be pretty decent. Now it takes something
like 10 clicks to delete a card.

The rest of their interface is chock full of antipatterns like that.

Someone needs to build something that does one thing well and doesn't try to
do every other thing under the sun.

------
jimnotgym
I'm not going to defend Jira, but don't you just need to break down each
ticket into smaller ones.

To use their metaphor. The airport gets a ticket. Then you put another ticket
up that says 'find a good field to land in', then another that says 'level out
field for x class of plane', then another that says 'install basic lights'etc.

Things are now getting marked complete and you are agile all over again.

~~~
rabidrat
What if that turns out to be an inefficient (poorly-architected) way to break
it down? But it's half-implemented by the time someone calls attention to it,
and it doesn't get re-architected because it's too late now.

Breaking things down appropriately is, in my mind, 80% of the work. If you
have your head straight, the implementation is easy; but it can take
implementing virtually the entire thing to get your head straight.

~~~
jimnotgym
> What if that turns out to be an inefficient (poorly-architected) way to
> break it down?

Don't break out later stages too early then! Just enough to get to MVP. That
is the essence of agile and XP isn't it?

~~~
rabidrat
If I don't break them out "too early" then that often means I'm not breaking
them out until I'm almost finished :)

~~~
jimnotgym
> but it can take implementing virtually the entire thing to get your head
> straight.

Seems to fit your needs then!

~~~
randomdata
Well, the developer didn't need it in the first place. It is not a useful tool
for developers as we have better tools for developers. It is management that
wants to see the work up in pretty JIRA lights and they want to see it before
the project is already done.

------
Cyclone_
Jira has always been very quick and responsive for me. It offers a good amount
of customization too, we have a custom workflow that makes sense for how we
develop software. I've never felt that jira has been a limiting factor of what
the teams I've been on have wanted to do with our workflow. Never once
encountered a major bug in it either.

~~~
iainmerrick
It’s infuriatingly slow for me. Is this a configuration thing? Are our teams
doing something different?

It seems to me that it’s slow on a number of levels. It just takes a long time
to load each page, and on top of that, basic operations usually take far too
many clicks. So I figured it was just a bad tool.

~~~
slider_thor
Jira Cloud & Jira Server (on-premise) are two different beasts. I can speak
for on-premise only. On my on-premise system which is located on the other
coast of the country, a ticket loads in 1.5 ~ 2.5 seconds once your assets are
cached at least once by your browser.

Things I've seen that can adversely affect your speed: installing random
plugins that are poorly written, integrations, having too many admins over-
complicating the Jira configuration.

Learn the keyboard shortcuts to speed up your basic operations.

~~~
iainmerrick
1.5–2.5 seconds is slow. (Faster than I’m getting, though, I’ll give you
that.)

------
temporallobe
JIRA is not a drop-in replacement for good ol’ fashioned software design and
documentation, and no one ever said it was. The author mentions things like
common models and complex cross-application components. Who ever said JIRA was
supposed to somehow capture those things? It’s not! If you’re using JIRA for
things like that, you’re doing it wrong.

I think the danger is that JIRA IS being used more and more as a design and
documentation tool while we ngleglect using some of the more well-established
practices of years past, such as use-case diagrams, class diagrams,
requirements documents, wireframes, etc. We try to capture too much design in
the various types of tickets, but that in my opinion is wrong because JIRA was
not originally designed for that. In that way, JIRA itself is not a anti-
pattern, but how we use it certainly can be.

------
jedberg
What this article seems to be missing, as does most of the comments here, is
the distinction between software engineers and architects. Everyone likes to
rip on the “architects that do no real work”, but this is exactly the problem
and architect solves.

Their job is to understand the macro picture, the user’s use cases and the
business use cases, and be technical enough to then digest that all into
tickets of small chunks of work such that the software engineer can implement
the right thing. It is the architect that holds the context and hopefully
passes the right amount of that context through the ticket.

In the author’s metaphor, it would be the architect who would design the
electric and water grid and decide which houses go where and who will build
them and how. And then monitor the whole project and change things as issues
come up.

------
aidenn0
> Isn’t agile development supposed to be fundamentally different from
> waterfall development, rather than simply replacing one big waterfall with a
> thousand little ones?

A thousand little waterfalls is fundamentally different from one big
waterfall. One major issue with waterfall is that one mistake anywhere in the
process can derail the entire project, and those mistakes are not always
apparent until very far in.

If your waterfalls all complete in say, under 2 months, then you don't lose
any more than 2 months with any single item that is a total failure (partial
failures can be even less disruptive).

I'm not the biggest fan of the word "agile" but this idea seems like a very
important point of many things that call themselves agile, and it damages the
ethos of the author's argument to have such a basic misunderstanding.

------
flocial
This is a beautifully written article but at the end of the day the way a
business uses a tool says more about the organization than the tool itself.

Is Jira a tool of oppression or liberation? It can be misused by managers to
bully whip a chain gang or just as easily become a developer's best friend
when a performance review is coming up (the same way a rock solid alibi will
help you survive police questioning).

While I agree about how wonderful it could be if used right, it's easily
abused and hard to remedy once it becomes a todo list from hell. My guess is
the larger your organization and the more rigid your corporate culture is the
benefits of tools like Jira will outweigh the cons (not mention the lock in
effect once it's adopted).

------
gamesbrainiac
Most people reading this article will miss the point. Many will conflate what
the right way of doing things is. However, the main point is that JIRA makes
the things that you should do, harder while at the same time, making the
things you shouldn't do easier.

------
angry_octet
You can use a good tool to implement a bad software development practice. The
focus on closing tickets comes from people who are too focused on the details
and covering their patch, and that will happen with or without JIRA.

------
tomohawk
This is absolutely correct. I've seen the analogy of the city build-out occur
again and again as teams become fixated on tickets instead of understanding
the overall problem and architecture.

------
afro88
The way he described the organically grown city is certainly a way to do
things in Jira. Just write your tickets that way. Don't have a ticket for a
whole block, or a whole airport. Have a ticket for the dirt airstrip. Don't
write all your tickets in the beginning, write them as things progress.

Going back to the start of the article: have a ticket for the caching of the
3rd party service, have a ticket for your data model (your engineering team
might be the person the story is centered on in these cases).

------
ryandrake
Whenever one of these discussions starts, it's usually about 50% of the
complainers saying "I don't specifically like JIRA" and 50% saying "This isn't
about JIRA--I don't like the idea of using any kind of ticketing system to
plan, track, and execute projects".

The first argument is fine. Personal preference. You might have a different
one you like best. I've used close to a dozen issue trackers, and to me JIRA
is pretty much middle of the road. Not great, not cancer. It does a job, and
is kind of a pain to configure. But to argue against the very idea of tracking
bugs and features in a database? That's kind of bonkers unless you're a one-
person development team and also double as the product owner, UI designer, and
QA tester, and you don't have managers or other stakeholders who want to be
able to know how far along the project is.

When your team size is >1 and you have more than a single day of work to do on
the project, you need _some kind of tool_ to organize and coordinate planning,
design, development and testing activities. What are you going to use? Excel?
Handwritten notes? I'd love to hear from developers who successfully finished
a team development project without a bug tracker. At the risk of staking out a
provocative position: I don't think it's even possible.

------
crankylinuxuser
Usual of tech writing - set up a false premise, answer with bad solution, and
then summarily tear it to shreds. I work in an agile environment, and our
ticketing system is Jira/Confluence. And I do _not_ see what this person is
talking about.

1\. Agile tickets include a 'Story', which says "As $person, I'd like to be
able to do XYZ." The very ticket entails a basic line of sanity checking to
prevent 'do ticket->close ticket->dont care' loop.

2\. One rarer things with Agile is 'Desk Check' (
[https://www.techopedia.com/definition/18825/desk-
check](https://www.techopedia.com/definition/18825/desk-check) ). This is when
a new thing by devs is done, and then they pull the designer AND qa at the
dev's desk and do a sanity check on the very card, __before __it moves on.
This solves design misunderstandings and potential QA misunderstandings /bad
process before continuing.

3\. Spikes are done to determine how big a major thing can be. It's a first
round rough draft of 'how big is this feature, really'? The result from a
spike can then be made into an epic. The epic is a way a person doing tickets
can understand the big picture.

------
jasode
_> But you need something else for the macro. [...] Allow me to propose
something shocking and revolutionary: prose.

[...]

But it is a tool deeply ill-suited to be the map of a project’s overall vision
or infrastructure, and it is never the source of truth — the source of truth
is always the running code._

I'm not sure what Jon Evans means by "prose" to document the "macro vision"...
a freeform text file? MS Word doc?

Personally, I need more structure than that so I use a spreadsheet for it. I
like to create columns of metadata to assign a priority, notes about
difficulty, estimated time, estimated cost, etc. Any large project will have
_hundreds_ of wishlist features that need to be organized. Prose is too
unstructured for that. Maybe JIRA is too bureaucratic and the wrong tool too;
I'm not familiar with its goal-planning tools.

I can't store the "macro vision" directly in source code because many wishlist
goals are greater in scope than placing a commented out line in a cpp file
such as _" //TODO:implement voice recognition."_

Yes, the source code is a "source of truth" but it's only truthful at the
abstraction level of generating an executable. It's the wrong abstraction for
gathering wishlists, future goals, and priorities.

~~~
geocar
> I'm not sure what Jon Evans means by "prose" to document the "macro
> vision"... a freeform text file? MS Word doc?

Yes. Sometimes.

> Personally, I need more structure than that so I use a spreadsheet for it. I
> like to create columns of metadata to assign a priority, notes about
> difficulty, estimated time, estimated cost, etc.

I think having a spreadsheet is good too.

This isn't either/or.

> Yes, the source code is a "source of truth" but it's only truthful at the
> abstraction level of generating an executable. It's the wrong abstraction
> for gathering wishlists and future goals and priorities.

I don't think that's what is meant by this statement: _the source of truth is
always the running code._ I read it a call for an iterative and evolving
"design" that comes from the program _as it is run_ , instead of some
repository of code or tickets.

~~~
jasode
_> This isn't either/or._

To engage with JE's particular essay, I think it is _either /or_. He
emphasized "prose" with _italics_. Seems a reasonable interpretation is that
he thinks the _rigid or incorrect structure_ in Jira is wrong to document a
macro vision. If he thinks another structured tool like MS Excel or MS Project
is a desirable alternative, it seems he would have mentioned it. Instead, he
recommends _prose_.

To be pedantic, one can type "prose" right into Jira. But that would be an
uncharitable reading of his essay. Therefore, he must mean something else: a
document that's more freeform.

 _> I read it a call for an iterative and evolving "design" that comes from
the program as it is run_

If he meant that, he's wrong because the _running program_ is always an
incomplete picture of what you _desire_ the program to do. The "desires,
goals, and design" \-- ultimately has to be stored outside of the source code
and therefore, it can't be a source of truth for that type of macro vision.

(Yes, there is a school of thought that proposes that _" the source code _is_
the design"_ but I've always seen that as more of a reaction to UML diagrams
and flowcharts from CASE tools that get out of sync with the actual code. To
really fulfill the "code is design", it would require an extremely powerful
declarative language compiler that turns high-level English specifications
into executable code. Using today's primitive languages such as cpp and h
files isn't a good way to express "code is design".)

~~~
geocar
I think you misunderstood me/I was unclear.

Yes, the macro-level view belongs in prose. In a word-doc perhaps.

All I meant was that this doesn't preclude the use of tools like Excel (or
Jira) to break up tasks into items and estimate their cost. If you like doing
that, then great: you're not doing anything wrong.

------
luord
Disagree on the implication that the kanban flow (which is essentially what he
described by moving stories between different phases) is inherently a
waterfall; it is in as much as the idea that a project is expected to be
completed (or at least reach feature completeness) at some point is a
waterfall. _Scrum_ [1] often does become a collection of short waterfalls, but
nothing in the kanban flow prevents a story moving in any direction.

He says that epics are not enough to depict the bird's eye view on the
project... But he doesn't elaborate _how_ and I certainly disagree.

And the city construction analogy is a flawed one. Cities _are_ , in 99.9% of
cases, hackjobs cobbled together over hundreds of thousands of years. There
are very few cities that were planned from scratch.

The "extension to the metaphor" he mentions is essentially every software
project --organized process or not-- and it's the archetypal example of the
software crisis. Maybe programs are not cities...

I also have a very different concept of "huge requirements document" because
what he described as alternative is very much a huge requirements document.

The comparison to art (even if there's always an inherent artistry in software
development) is because he talks about art using "shoulds". No, there are no
rules for art, while there should be rules for software development (even if
they ought to be flexible).

[1] Actually, most of the complaints I agree with (points, too many meetings,
loss of the macro view, pressure to deliver whatever at every point and in a
set of defined stages) are mostly about scrum, which can be run without jira
or any other tools.

------
rhacker
We use Jira but it has such a vast disconnect from how the mind works. I'd
rather have a shared document that has one liners like so:

    
    
        New reconciliation engine
            [x] Migrate to new prod db
            [ ] Add feature to copy study objects (jim can explain)
            [ ] Move study list rest service to graphql
            ...
        
        Inverted micro editor
            [ ] ...

~~~
hliyan
Interestingly, if you copy & paste the above text into a Github issue
description, you'll see that it works exactly as expected.

My problem with Github issues: need "Affected Release", "Fix Release" fields.

------
cvs268

      > But if measured by how many blocks and neighborhoods are absolutely finished,
      > according to the urban planners’ artistic renditions,what is your progress?
      > By that measure, your progress is zero.
    

Exactly! Do NOT create individual JIRA Task the size of each building/block.
When planning a city, a JIRA Task is something like -

 _" Add switches to the bedroom of apartment 104 in the residential building
at lot #10 on Sunshine street."_

No wonder the author of this Techcrunch article is frustrated with JIRA. He is
using JIRA wrong (or more likely is being forced to use JIRA incorrectly)

One of the cardinal sins of project planning is to NOT decompose the
activities into individual deterministic steps.

I have summarised my thoughts in this slide-deck that i find useful in my
crusade against unplanned/misplanned projects
[https://thecodeartist.blogspot.com/2017/04/effort-
estimation...](https://thecodeartist.blogspot.com/2017/04/effort-
estimation.html)

------
jondubois
Jira is one of those tools which tend to give managers an illusion of progress
at the expense of actual progress. It's not just Jira, there are many tools
today which are like that; they aim to give non-technical managers a feeling
of control over a technical process which they are often not capable of
understanding. These tools are designed to allow non-technical project
managers to not trust their technical people - This is a recipe for poor
quality results. The best CEO and CTO that I've ever worked for used Trello as
their only project management platform and they personally kept tabs on all
the main tasks; even as the company grew. They had a good intuitive
understanding of how long things should take.

There is a really big difference between seeing what needs to be done versus
understanding what needs to be done; no amount of advanced project management
tooling can make a manager actually understand what is happening.

------
starky
As someone that uses JIRA for hardware development and hates it, this article
really speaks to why it is such a pain point. There is often a lot of moving
parts going on in a project, and there isn't much to put down until a task is
done, at which point it feels pointless to say anything more than
"Temperatures were all found to be within specification. Test report
attached." Where something with a much higher level view of the project (maybe
deliverables based) would be more useful. When we do have an issue that could
be useful to track the status with comments over time, it is such an emergency
that nobody documents it until after it is resolved, and you would be lucky to
find it in the future with the terrible search anyway.

------
blufor
My team (well, mostly just me) are pioneering Phabricator as a replacement for
the Atlassian suite. Phabricator has been born in Facebook (it looks a little
like FB in 00's :)).

Main advantages:

\- It's rather a framework with dozens of small apps that adhere to the KISS
principle

\- Core elements are Users, Projects, Tasks, Repos (git, svn or hg) and
Differentials (like PRs)

\- Has shitload more, like Pastebin for example

\- Task can be in multiple projects/views

\- Tasks can have parent/child relationships

\- Task can mention other tasks and objects

\- Has an app called Herald, which handles event-based hooks

\- Has a CLI tool called Arcanist which replaces git (well, it's rather a
wrapper that adds few api calls)

\- Allows you customize the system to YOUR workflow, not the other way around

Disadvantages:

\- PHP (even for the CLI tool)

\- MySQL

One of the benefits no other tool gave me is that I can backtrack from a line
of code to the original Task or its parent epic.

~~~
blufor
Missed the links

[https://www.phacility.com/phabricator/](https://www.phacility.com/phabricator/)

[https://github.com/phacility/phabricator](https://github.com/phacility/phabricator)

------
HeavyStorm
I wonder why this received so much attention. I'm not a JIRA advocate, but the
author seems to have missed a lot of what JIRA is about and is just venting
about some badly managed project he experienced, and, as most of of us do, is
blaming the tool for the human mistakes.

There's somewhere a conversation worth having, like how everything is an issue
on JIRA (which most open source projects follow anyway) and indeed how agile
methodology seems to to push us to forget about the big picture sometimes, but
certainly blaming the tool for granularity issues of the stories is completely
unfounded.

Besides, it works - I've delivery many projects using the tool effectively,
even if sometimes I wish all I had was a kanbam.

------
dboreham
I've yet to see a bug system that is anything close to as good ss Bugzilla was
in 1998.

~~~
hmottestad
What was good with Bugzilla that you miss from the likes of Jira?

~~~
achamayou
The good thing about Bugzilla was that it was clearly a bug tracking system
(and it was excellent at that), whereas Jira is only a passable bug tracking
system pretending to be a project management tool.

~~~
hmottestad
Can you be more specific? What is missing

I've used Jira for quite a few years at work, and the number one issue with
Jira that I have found (and also my team) is that bugs that don't get fixed
tend to get lost in the mass of everything registered in Jira.

Jira does try to both be a place to register bugs (and features and other
tasks) while also trying to be a place where you organise how the work should
be done (eg. with sprints). I guess Bugzilla doesn't do that?

~~~
achamayou
A good bug entry is (completely) unlike a project planning entry. It comes
with detailed environment and repro instructions, artefacts such as logs and
screenshots. It’s an investigation, not an item in a wish list, and it’s
ideally a place where every dev in the team can chip in and offer additional
data or suggestions.

If it isn’t used to track progress or productivity, it contains exactly the
right number of entries (since there is no incentive to the contrary). The
criteria for closing a ticket are very clear, there is no risk to offend
someone by closing their half implemented and ultimately insufficiently
detailed entry for example. Bugs are either open or fixed!

The tool does not figure out who should be fixing which bug, that’s the job of
the team lead.

When an issue falls on the fence between a feature request and a bug, whoever
is allowed to make the call needs to decide and either keep it as a bug, or
mark it as wontfix (either out of scope, or to be looked into as a feature).

A well maintained bug tracker is valuable to users, because it comes with a
good search implementation (Jira’s search is abysmal for error messages!), and
then can work if and when the problem they hit has been fixed. Cluttering that
with project management does not help!

------
Annatar
"Tickets, in the JIRA mindset, are taken on, focused on until complete, and
then passed on, never to be seen again. They have a one-way lifecycle:
specification; design; development; testing; release. Doesn’t that sound a
little … um … waterfall-y?"

It does, because when cold, hard reality hits, the waterfall workflow is the
one and only way to _system engineer_ high quality software; there is nothing
else and there never was any other technique to achieve that. Agile is a
gimmick to give non-engineers free reign, carte blache to keep on hacking like
mad until something somewhere finally starts half-working; that's the hard
reality of the IT industry.

------
ineedasername
Isn't this a product of the agile method though, and jira simply instantiates
it? the whole epic -> story -> subtask methodology seems to be a large part of
the article's complaint, but that's really not jira's fault.

------
dajonker
I often see a bad split between the ideas/specifications, and execution of a
software project. On one side there's the project style where everything is
designed and specified by non-programmers (i.e. people who don't end up coding
the thing), then thrown to the programmers to make it work. On the other hand
there's plenty of programmers that just want to write beautiful code and care
little about how useful the result is. In my opinion you get better results
when most people involved are fundamentally problem solvers, some happen to be
awesome at writing code, and all are working together closely.

------
makecheck
The more these things try to be, the worse they seem to fail at the basics. We
desperately need more solid basics in our everyday tools.

I want JIRA to just _load_ and _display_ the simplest of content, and it often
_doesn’t_. There is no way to predict when Unexpected Server Lag will occur
either. If you believe Murphy’s Law, it’ll happen exactly when I finished
typing a long-ish important update to a bug that then won’t submit (and like
too many web tools, you’re screwed at that point: there’s no sensible way to
“stop” it and you’re 90% sure that “Back” will erase everything you just
wrote).

------
evrydayhustling
> What’s more, feature-driven JIRA does not easily support the concept of
> project-wide infrastructure which does not map to individual features... the
> spiderweb of dependencies which result don’t help anyone.

Disagree. You can make projects about infrastructure, and talk about releasing
features of the infrastructure -- e.g. a new parameter in your cache
interface. If this grates -- perhaps your description of an infrastructure
update includes updating all clients which could utilize the update? -- then
you may be facing productive pressure to decouple systems by defining and
versioning an interface.

------
donjoe
Building a city/neighborhood is a really bad example for an agile development
tool: agile development is to be used in case requirements are not yet fully
available.

In other words, the team is searching for the right and best solution to solve
a problem.

In the author's example, the city is already fully planned and ready to be
build, thus the solution to solve an existing problem already exists. Why to
use agile?

Building a city/neighborhood is a perfect example for a waterfall
implementation strategy which can be perfectly modeled with other tools.

As always - use the right tool for the right job and you'll be alright ;)

------
yashksagar
I don't think the analogy of town planning fits well. I think it depends how
the tasks are broken down by the team. What if the tasks are created in the
breadth-first approach, so that the goal is not to "fully complete" each
neighborhood, but to get each neighborhood in a working state, like the
"organic" approach the author mentioned?

I have found success using this approach on my team. And yes, agreed that we
should use other software like Docs or Sheets for the project homebase, and
only limit JIRA to Epics/stories tied to labels for the projects.

------
kaio
That article is really awfull in expressing the root cause of the authors
unhappiness with agile and enterprise scrum. Jira is just a tool. To stick
with bad anaologies: how can a screwdriver be an antipattern?

------
DevKoala
I feel you get as much of the tool as you are willing to put into it. I
personally abhor the tool and prefer working with engineers who can own full
services and applications from end to end. That way the discussions are held
at the architectural interface level with the goal in sight always.

I have only found JIRA is useful for tracking the implementation tangential
TODO items such as monitoring and alerting, extra data validations, UI style
items, etc; tasks that other engineers can implement without the need to
understand the full scope and architecture of the project.

------
znpy
I understood that the article was flawed from the point where the author
called software engineers "crafters".

That being said, we use Jira at work and it has been serving us well. Really,
I can't complain.

------
DyslexicAtheist
off-topic but using Jira (developed by Australia based Atlassian) sounds like
a massive security risk due to "aabill".

checking twitter there isn't even a statement by Atlassian or any critic of
the bill. looks like Australian tech companies simply don't care
[https://twitter.com/search?q=%40atlassian%20aabill&src=typd](https://twitter.com/search?q=%40atlassian%20aabill&src=typd)

Btw FastMail too is based in Australia (and in comparison to Atlassian is at
least vocal against the bill).

------
diiq
I use vistimo.com for tracking what I build for clients; I built it
specifically to alleviate the harm of the linear backlog, and help everyone
share the same broad vision of where we're going, how long it will take, and
what's changed about the plan.

Storymapping isn't a perfect tool for sharing product vision, and by trying to
be storymapping+estimation+progress tracking, Vistimo is of course imperfect
at each of those things individually; but having the combination has done me
and my clients a lot of good.

------
Myrmornis
I admire the author of this piece for being able to concentrate on the bigger
picture of how JIRA is bad in important ways, despite the millions of ways
that JIRA is bad in minor ways that make anyone who uses it absolutely hate it
for trivial reasons without even getting to think about the bigger picture.

If you were going to decide not to support markdown, wouldn't that decision
make more sense if you had front end engineers who were even vaguely capable
of implementing a custom mark-up language?

------
jib
Feature decomposition is an antipattern. This is not related to JIRA. Features
are the result of integration of systems. Starting with features is insane.
Design the system, then integrate parts of the system to create features. I
don’t think prose is the answer, but it certainly sounds better than starting
with features.

If you get the chance I’d recommend taking the architect/project design master
classes by Jowal Lowy. If you can stand the delivery the message is extremely
on point.

------
jimjimjim
I've found jira works fine except for two things: 1) it's been around for a
long time and still doesn't seem to be a good match for agile and 2) once
people drink the kool-aid it starts getting used for everything.

It works great as a todo list of things that need to be done.

But lots of places treat it as the single source of truth and stuff it full
with every thing from high-level decisions down to acceptance criteria
describing the color of a button.

------
moron4hire
JIRA is a pretty flexible tool. We use it primarily because it _is_ a ticket
list that we've been able to get approved in our corporate IT system.
Personally, I prefer Trello, but no tool is going to be a substitute for good
management. If your projects are failing, it's because of lack of
communication in the team, which will happen with even the best tools, and can
be done well without even the worst tools.

------
passive
I've worked with JIRA (and Confluence) on a daily basis for the last 6 years.
During that time, I have personally spent months of time working _on_ JIRA, to
make it do what we wanted. Before that, I worked with JIRA on-and-off for 7
years (with Trac and Rally tagging in here and there).

Which is all to say, I know me some JIRA.

The fundamental thing that this article points out is that JIRA tickets are
about _work_ , not software, and as a consequence of wanting to track our
software, most users of JIRA spend a considerable amount of time and money
approximating the tracking of software.

(No, Confluence isn't for tracking software either. It's for filling in the
more flexible pieces of data that JIRA doesn't handle so well.)

This is correct, but I would say calling it an antipattern is going too far. A
well-customized JIRA is probably the best system in existence for
approximating the tracking of software.

But (probably _) it doesn 't have to be, which is hopefully where the author
was trying to get. Something like Github issues, for example, binds code to
"tickets", which at least conceptually is a step in the right direction. But
software is quite a bit more than code, which is why our JIRA has tickets
related to provisioning infrastructure, deploying, managing data, etc. I'm not
aware of any JIRA alternative that considers all these facets of software
creation holistically, though it's been a year or two since I looked into it
seriously.

_there are a lot of ways to develop software, and maybe designing a useful
system that encompasses all potential aspects becomes too abstract to actually
be efficient.

What I can conceive of is something of a mash up between JIRA and BDD, where
desired changes are first described as a new end-state, and then the necessary
work to achieve (and automatically validate) that state is broken off in
tickets that are linked to that end-state description in some way. The key
being that that first description is always your source of truth about the
software, with the linked tickets helping organize the work before it is
ready, and serving as reference information afterwards.

We are close to approximating something like this with Gitlab, JIRA, and
Radish-BDD, but it's a lot of wiring and educating about conventions. I think
you could do it in a single piece of software.

------
hnruss
It is the responsibility of the product owner to write requirements in such a
way that also conveys the big picture. It is the responsibility of the
engineer to understand the big picture before implementing requirements.
Perhaps Jira could be improved to encourage better communication about the big
picture. I’m sure there are plenty of other ways to do that already, though.

------
paulie_a
Jira tickets are generally devoid of specific information. What am I actually
expected to do. List it out. User stories are an incredibly useless concept in
the current implementation. And the new interface on jira is a piece of shit.
I will say it again, jira sucks when it comes to UI.

Just because a ticket exists doesn't mean it has useful info or potentially
matters anymore.

------
haglin
It depends on how you use it.

You can create a design ticket where you describe the larger overall picture
(city planning) and then as you implement it, add enhancements (neighbourhoods
and sewers) as subtasks. If something breaks when you add the enhancement, for
example a memory leak when calling method X, you can create a bug ticket that
only concerns the micro details.

------
adrianmonk
Jira is a tool for executing the implementation portion of your software.
Notice I did not say implementation phase. Also notice there is a design
portion of software.

It's important to distinguish between design and implementation. Creating a
plan is not the same thing as executing the plan. All these things can overlap
and have feedback in both directions.

------
catchmeifyoucan
I find Azure Devops (VSTS) to be just as poorly designed for this purpose of
macro design. Work isn't a linear process.

~~~
alkonaut
VSTS and Jira are two implementations of the same thing really. They are the
two large enterprisey issue management suites.

They are "the worst except for all the others".

If you really _are_ a huge enterprisey team that has many levels of visibility
for various management levels and stakeholders, as well as large distributed
teams working with different schedules and modules, then github tags or post-
it notes eventually won't cut it. They are nice and streamlined for a while,
but then someone will ask for a weekly report of X or a website showing
progress Y and a corollary to my main argument is that _someone_ is always to
oblige with the request even though the correct answer may be "no! Let us just
use streamlined tools and just make smaller independent teams!".

And in the end if you start off with post-its, the github issue tracker or
some lightweight issue management system you'll end up according to this
theorem:

 _Every software project management system in a large enterprise environment
that isn 't already a large enterprise one (like Jira), will eventually become
an ad-hoc, informally-specified implementation of Jira_.

------
beefhash
It is, however, not a new antipattern. This kind of thing has been around
since the 80s or at the very least since the POSIX standardization of SCCS.

Even SCCS supported something called "modification request" numbers. These
could optionally be checked by an external executable, tracing each commit
back to a ticket number.

------
sheeshkebab
To paraphrase Winston Churchill, JIRA is the worst tracking tool, except for
all the others.

[https://winstonchurchill.org/resources/quotes/the-worst-
form...](https://winstonchurchill.org/resources/quotes/the-worst-form-of-
government/)

------
warpsprung
As a bug tracker YouTrack seems to be much more usable and more powerful than
JIRA. If you want a bigger system for everything including Requirements
Engineering give codeBeamer from Intland.com a try. Everything is freely
configurable. Much better than the typical ALM systems.

------
tmaly
I use JIRA in conjunction with Confluence in my teams software process.
Confluence holds the requirements and specifications. The project starts there
and work on the specification is partitioned into JIRA tasks.

So I do not have this issue with macro and micro views of a project.

------
bmjunk
How about we replace all the "Agile and Scrum" bullsh*t jargon and principles
with a simple framework called "Common Sense". Do what makes sense for your
user and your business. Everything else falls into place automatically.

------
mooreds
We are looking at planning tools (digital agency, many clients with needs that
rise and fall, small team of developers). We would love to have a time based
resource planning view.

Weren't really considering jira, but would love to hear any suggestions.

~~~
tdrgabi
How about a Gantt chart? It's a time based resource planner.

------
Izkata
This line:

> (If you prefer a smaller-scale model, just transpose: city → condo building,
> neighborhood → floor, block → unit, etc.)

is where I realized why this whole post felt wrong. This _is_ how cities are
built, a handful of buildings at a time, Jira-style.

------
jugg1es
Doesn't this have more to do with how people are using the tool rather than
how JIRA markets it? If you expect one piece of software to solve all your
problems, then you don't know a lot about how software gets designed.

------
vePhi4le
[http://tom.preston-werner.com/2010/08/23/readme-driven-
devel...](http://tom.preston-werner.com/2010/08/23/readme-driven-
development.html)

------
techntoke
Issue & project tracking belongs in tools like GitLab or Phabricator, not
JIRA.

------
drb91
This seems to be railing against the concept of beureaucracy, which JIRA
naturally reflects. Is this really tool-oriented at all? All criticisms here
could be levied against Trello, Asana, or post-it notes on a wall.

~~~
pspeter3
Can you elaborate?

------
lucas_membrane
Biggest problem when I used it, could not assign anything to more than 1
person.

------
matchagaucho
_" JIRA encourages the disintegration of the macro vision."_

That's a questionable use of the tool. _Decomposition_ is the agile approach,
with modular deliverables that can be parlayed into future stories.

------
rs23296008n1
JIRA is a good way to weed out organisations I will probably not enjoy working
with. Kind of like if the interviewer says they have a COBOL or java codebase
"they'd like me to look at" even though neither is on my resume.

Ironically this is not a criticism of JIRA itself. I use it now like I'd use a
woman's bad hair on a date or her declaring her borderline personality
disorder at dinner. It's a form of red flag detection / future horrible
incident avoidance.

The problem with agile/scrum and jira is that it is frequently deployed as a
form of snake oil with the expectation that it will instantly solve all that
ails them. Instead of something that requires actual support, procedures,
daily action as well as simple management follow through to succeed.

------
democracy
Jira used to be hip and all, being written in Java helped with early adoption
but these days it is a monster and reminds of me HP QC monstrosity - which is
exactly why we moved off HP to Jira long time ago.

------
iainmerrick
If Jira is a good tool for making software, why isn’t Jira itself better?

~~~
anonytrary
Because when Jira was made, Jira didn't exist, so Jira didn't have the benefit
of using Jira. /s

~~~
iainmerrick
So refactor it!

------
linuxhansl
It's just a tool...

We use it a lot for Apache Open Source projects. It's good enough to keep
tracks of what's a release, etc.

Of course you do not use for mini-specs, etc.

------
jkdll
The problem in this article can be easily solved by carrying out 'Story
Mapping' \- the problems mentioned come from not carrying out story mapping in
a visible way.

The best Product Owners I know have been carrying this process out manually
for a long time, but there are also plugins for this:
[https://www.featuremap.co/en/integration-
jira](https://www.featuremap.co/en/integration-jira) (I am not affiliated with
this product).

This is a case of a bad workman blaming his tools.

------
m3kw9
There is always a document outside of JIRA that describes high level, just
have to find it. I really don’t think this is a JIRA problem.

------
Ericson2314
The number 1 feature in all these tools should be dependencies. And yet it's
always a stupid afterthought with no love.

------
rawoke083600
oh yes ! Jira... everything is possible but nothing is easy... my next
software/project-management package i buy,i want to buy a methodology... i.e
"we acme inc have figured out how to best track/manage software projects"...
NOT here is a tool you can customise to fit every possible scenario and
methodoloy...

------
mbrodersen
JIRA works great for me and the company I work for. Don't blame the tool if
you don't know how to use it.

------
geophile
TFA says that the problem is Agile run by bad managers. Why the hate for this
tool used to implement Agile?

------
optimuspaul
JIRA isn't an antipattern, but it does enable people/teams to use
antipatterns. This is silly.

------
iblaine
Just because a tool gives you enough rope to hang yourself with, doesn't mean
it's a bad tool.

------
leowoo91
Isn't that the fact most products get bloated over time, especially when
funded in wrong ways?

------
trixie_
If I had a nickel for every time a PM was proud of themselves for creating a
zillion tickets...

~~~
yyx
If I had a nickel for every time a PM didn't create a ticket…

~~~
trixie_
If I had a nickel for every time a developer was unable to create their own
ticket.

------
yason
Any discussion about the relative merits of task tracking software is moot
because of fundamental discrepancies with regard to tracking tasks.

Programmers don't need task tracking. They have an in-head priority queue of
stuff that needs to be done, and often doing that stuff will cause insertions
into the queue that will completely reshape it. If you make a copy of that
queue into a system the result is a pixellated representation of the original
data and it's probably outdated by the time you finish making the copy.
Programmers might have a TODO.txt or a post-it somewhere to remind them to not
forget some unrelated stuff, but generally once a programmer knows what needs
to be done and why the work will partition itself, in the right order, and
into right sized chunks. The queue is rather alive and zooms in and out all
the time.

Managers don't need task tracking either but they think they do. What they
need is a way to measure progress and completion. A manager's task queue is a
very different queue from what the programmers have in their head. Most of the
time, you can't map items from the programmer's queue into the manager's
queue. The reason is that in the programmer's queue all items take the time it
takes to complete items and thus items come in different sizes. In the
manager's queue the items have time estimations and progress percentages and
they're split into manageable chunks of time; if not hours at least usually
days.

So, managers get this idea that they can ask programmers to maintain a copy of
their internal queue and save time and effort by reporting progress from
there. Usually this takes the form of a task tracking system. The pixellated
result that managers get from the programmer's queue is _data_ which managers
then need to reinterpret as _information_ when reporting up. All they need to
report back to other managers and higher ups is the progress, how well the
work is within the estimates and when will it be complete, and a few answers
to "whys" of what's causing delays or why something new needed to be done. But
the programmer's queue has none of this information so dilbertesque creativity
is unavoidable during converting programmer items to manager items, dragging
everything farther from the truth especially if the managerial copy is ever
fed back to engineers.

The programmer will think the result is ridiculous and doesn't at all match
what's in his own queue. The manager can't see what's exactly wrong with it
except that programmers are bad making estimations and the tasks are badly
scoped and larger than they were planned, thus completion is prolonged each
week.

A signs of this happening is that tasks being tracked don't match with the
tasks being worked on. There's some overlap but some tasks are suspiciously
simple while others are too vague, and there's unreported invisible work that
sometimes takes the majority of the wallclock hours of a week. The programmer
could only ever supply correct information when everything is done and tested
while at that point the manager doesn't need it anymore as he can report back
"100% complete".

If the programmer is asked to provide more fine grained subtasks he will
either spend more time pleasing the manager rather than doing real work or he
will first work with no plan and no tasks for quite some time until he has
enough information to add the appropriate subtasks into the system.

Fine-grained tracking also eats into the free flow of the in-head queue of the
programmer: if rearranging the work queue (which happens all the time) gets
expensive it creates a barrier to let the work flow towards completion. The
programmer either gets stuck with the existing tasks or disregards the tracked
tasks completely and continues alone where the path of code takes him.

Regardless, the data in the manager's queue will certainly end up being
inaccurate, incomplete and outdated. Programmer also has to do extra work
simply to work around and between the manager's queue and his own queue.

No _system_ can fix this. Good communication is the key, and if you have that
you don't want a system to make it slower. Task trackers are useful for
individuals to keep things ordered to satisfy their own scheduling needs, but
they don't solve the inherent gap between managerial schedules and programmer
schedules.

------
snambi
Jira is an ugly ticketing software. Hope developers get rid of it ASAP.

------
jsilence
You can't blame the hammer for not holding the nail.

------
itomato
Flawed premise as Jira Software is not Jira and the Portfolio app addresses
their main complaint.

Junk article. They also point out that Jira is no longer in all caps but
couldn't be bothered to search and replace.

------
nurettin
jira is an antipattern because tickets could have been opened after careful
deliberation? Sounds like management's issue, not jira's.

------
black_13
Its used a replacement for planning and management.

------
alexnewman
jira and arc i would argue are timestamps. they are tools with a lot of power
but are less integrated then today’s state of the art

------
brightball
Most of these complaints are with Scrum IMO

------
omarish
Techcrunch is an antipattern.

------
arnonejoe
Amen.

------
diminoten
Almost everyone in this comment section is getting the article wrong.

> JIRA1 is all too often used in a way which makes it, inadvertently, an
> industry-wide “antipattern,"

Key phrase here is "all too often".

> That antipattern is not JIRA’s fault … exactly. But JIRA’s structure
> contributes to it.

> It’s very good when you’re at the point where breaking things down into
> small pieces and finishing them sequentially does make sense. And,
> unsurprisingly given its history, it’s exceedingly good at issue tracking.

These quotes seem to be missed by folks here.

This article isn't about JIRA, really, it's about JIRAs use across many
companies.

These comments are so transparently defensive, I'm actually surprised by how
poorly understood this article is.

------
suff
The author either does not know about 'macro' views e.g. burndown charts, or
is willfully ignorant. Also, obviously does not realize you can change the
custom set of ticket states to match your team's process. It absolutely allows
greater than 'one-way lifecycle'. Clearly there is a lack of familiarity with
the product.

~~~
shortlived
They also seem ignorant of the Portfolio plugin which provides a macro view
(above epic level).

------
notus
I don't understand why HN doesn't like or appreciate half assed comments, but
then posts like this are okay. All the poster demonstrated was that they don't
understand JIRA very well.

