Maria Montero

JIRA is an antipattern – TecNoticias, your information portal

The Atlassian JIRA started life as a bug tracking tool. However, today, it has become a nimble planning suite for planning, tracking, and launching great software. In many organizations it has become the main map of software projects, the center of all development, the infamous source of truth.

It is typical that the map is not the territory. Unfortunately, this seems especially true of JIRA. Its origin as a bug tracker, and its resulting use of "tickets" as its fundamental unit of definition, have made its maps especially difficult to follow. Jira1 is too often used in a way that inadvertently makes it an "anti-pattern" across the industry, that is, "a common response to a recurring problem that is generally ineffective and risks are highly counterproductive."

One thing that elegant software writing has in common with art: its creators must remain aware of the project's macro overview, while working on its smallest micro details. JIRA, unfortunately, implicitly teaches everyone to ignore the larger view while focusing on the details. There is not a whole. At best, there is an "Epic", but the heart of an Epic is to break it down into smaller pieces to work independently. JIRA encourages the breakdown of macro vision.

Also, feature-based JIRA does not easily support the concept of infrastructure for the entire project that does not correspond to individual features. A data model used throughout the project. A complex component used on multiple pages. A caching layer for a third-party interface. A background service that provides real-time data used on multiple screens. insurance may Guelos in the JIRA ticket paradigm … but the resulting web of dependencies does not help anyone.

Worst of all, however, is the endless implicit pressure for tickets to be marking finished, to go to the next phase. Tickets, in JIRA mindset, are taken, focused until completed, and then passed, so they are never seen again. They have a one-way life cycle: specification; design; development; tests; launching. Doesn't that sound a little … um … waterfall? Gil development is not supposed to be fundamentally different From waterfall development, instead of just replacing a large waterfall with a thousand small ones?

Here is an analogy. Imagine a city planning tool that makes it easy to design city maps that include towers, residential districts, parks, shopping malls, and roads … but that doesn't easily support things like waterworks, sewers, subway tunnels, the electrical grid , etc. ., which can only be embedded through awkward hacks, in any case.

Now imagine that this tool is used as a model for construction, with the implicit assumption that a) the neighborhood is the fundamental unit of city construction b) cities build one neighborhood at a time and neighborhoods one block a the time. What's more, one is incentivized to move on to the next only when the latter is absolutely complete, down to the flowers growing on the medium strips.

Now Imagine city developers, engineers, and construction workers are asked to estimate and report on progress in terms of how many neighborhoods and blocks have been completed in their entirety and how far each is. Do you find this a particularly effective model for urban planning? Do you think you would like to live in its result? Or, in practice, do you think that the best way to grow a city could be a little more organic?

Let's extend that metaphor. Suppose you started building the city in a more organic way, so that, at a significant point, you have a center filled with a mix of temporary and permanent buildings; the foundations of the skyscrapers were laid (that is, the technical uncertainty was resolved); much of the central infrastructure built; a few clusters of initial structures in the central neighborhoods, and slums on the outskirts; an airstrip where the airport is; and the traffic that comes and goes between all these places. In other words, you have built a crude but functioning city in process, your skeleton built, ready to be developed. Well done!

But if you measure by how many blocks and neighborhoods they are absolutely finishedAccording to the artistic interpretations of urban planners, what is their progress? By that measure, your progress is zero.

So that's not how JIRA encourages you to work. That will look like a huge column of tickets in progress and full zero. That would look beyond the terrible. Instead, JIRA encourages you to complete one complete block and then the next; an entire neighborhood, and then the next one; to remove as many different tickets as possible, to mark them as complete and transmit them, even if joining them after the fact is more difficult than building them to work together in the first place,.

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

And so, people take the tickets, implement them as they are written, pass them on to whoever is next in the workflow, consider their work to be well done, even if working in dispersed groups in parallel can be much more effective … and without even considering the greatest goals. "Implement the Load button" says the ticket; so that's all that's done. The ticket does not explain that the main purpose of the Upload button is to allow users to back up their work. It may be technically easier to automatically load each state change, so that the user gets automatic buttonless backups plus a full undo / redo stack. But all the ticket says is: "Implement the Load button". So that is all that is done.

Too often, the only time someone cares about the vision of the project as a whole is from the beginning, when the overworked project manager (s) initially grapple with the thankless task of breaking down the entire project. in a forest of Tickets. But the whole point A gil development is to accept that the project will always be changing over time and, although to a lesser extent, for several people, everyone on the team, to contribute to that change. JIRA has become a tool that really works against this.

(And I'm not even talking about asking engineers to estimate a project that someone else has broken down into subcomponents whose partition feels unnatural, giving them about thirty seconds per function during a planning meeting, and so basing the entire project plan on those half-blind guesses, without investigating, without investigating, without revisiting them or giving time for more careful analysis. That anti-pattern isn't JIRA's fault … exactly. But the JIRA structure contributes to this.