Death to JIRA

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

> 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)

> 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.)

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.

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

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)

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

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.

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.

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.

tl;dr Blame the tools.