Here’s an analogy. Imagine a city-planning tool which makes it easy to design city maps which do include towers, residential districts, parks, malls and roads … but which doesn’t easily support things like waterworks, sewers, subway tunnels, the electrical grid, etc., which can only be wedged in through awkward hacks, if at all.
I’m increasingly uncomfortable with using engineering analogies because I don’t know what they actually do instead. For all I know, maybe they actually DO use something exactly like this! Consider how bizarre a lot of CS things would seem from the outside: “imagine if we ran around crashing random servers in production just to see if we’d recover!”
From my admittedly limited experience with large construction projects. Those planning large construction projects create very detailed check lists in the form of gantt charts with everything that depends on other things happening being inputted into the list. They are updated at least once daily, often more so when things go ahead or behind schedule.
Very good for what-if analysis, so when the crane in use breaks and no others are available for two weeks you can see what that will be impacting two months down the line and plan accordingly.
Most processes can be distilled down to check lists and JIRA is just a fancy check list; however without being able to see the wider picture (e.g tree view or gantt chart) you can end up negatively affecting things further down the line that you weren’t aware of while working through your segmented list of tasks. From my experience JIRA forces you to focus on the details and ignore the wider picture and that is something I think this article is attempting to address.
I don’t think that’s the point. You can’t use analogies not in the common knowledge of the reader, otherwise you’ll make the topic even harder to grasp.
JIRA has its issues, but this is not a very good summary of them. I’m not sure that being able to visualize every single minute detail of a project should be a goal for any tool. What’s the value add from having a graph of your project and every single one of its dependencies?
Some of the grafs are just incomphrehensible:
One thing that writing elegant software has in common with art: its crafters should remain cognizant of the overall macro vision of the project at the same time they are working on its smallest micro details. JIRA, alas, implicitly teaches everyone to ignore the larger vision while focusing on details. There is no whole. At best there is an “Epic” — but the whole point of an Epic is to be decomposed into smaller pieces to be worked on independently. JIRA encourages the disintegration of the macro vision.
Some of them blame cultural issues on tool design:
So that is not how JIRA incentivizes you to work. That would look like a huge column of in-progress tickets, and zero complete ones. That would look beyond terrible. Instead, JIRA incentivizes you to complete an entire block, and then the next; an entire neighborhood, and then the next; to kill off as many different tickets as possible, to mark them complete and pass them on, even if splicing them together after the fact is more difficult than building them to work together in the first place.
Some of it posits that teams are using JIRA in a way that I’ve frankly never seen in the wild, has anyone seen this?
Simply ceasing to treat JIRA as the primary map and model of project completion undercuts a great deal of its implicit antipatternness.
Most teams I’ve seen use JIRA to break down projects that have been discussed or documented elsewhere.
It’s not a particularly good article, but enough devs will spontaneously and sympathetically upvote because “fuck jira” that the piece will get increased exposure, Techcrunch will get more ad impressions, his blog and twitter will get more traffic, and so on and so forth.
Precisely. See my comment above. Obviously anyone can post anything they want, but this kind of writing that optimized for clicks and splash isn’t something I feel will make the average developer’s life a better place.
I feel like the author’s primary complaint is against process. Jira is a tool. It’s flexible enough to implement many different processes. You don’t have to have mini-waterfalls. A ticket could have statuses of “To-do”, “In Progress” and “Done” and “In Progress” can be anything you want. Pair programming, test driven, etc. Or you can get detailed and enumerate all the specific steps.
No tool replaces having a good, clear process that people actually stick to.
I will agree that Jira is more focused to lower level, detailed tasking and higher level project goals can benefit from a different tool.
Yeah, this seems to be written by someone largely unfamiliar with Jira. Or familiar with only its use in a single company where it’s poorly managed.
I agree that you shouldn’t use Jira to define your process, but instead to describe and document your process. But I also think that Jira works fine with high-level project goals. Having a ticket type for “Project” or “Epic” that can be used for high-level prioritization seems to work reasonably well where I’ve seen it done. And you can even use (perhaps to the author’s shock) prose to describe the project and its status. Actually attaching work tickets to those project tickets is not required by Jira in any way.
Basically, tickets types can scale up and down, and have different workflows per ticket type (and even per Jira project). If you approach it like a generalized tracking tool, then it’s capable of modelling a huge number of processes, large and small.
I really love the proposed solution, but I doubt it would scale.
To me it’s the exact representation of how to coordinate people on a high level, if you now have 40 people working on a project for 5 years, you’ll find out that a 10 page document to describe everything might not be enough. You’d need way more documentation on what’s the purpose of a feature and how it should work.
This would be a good document to onboard people on the project and keep as a direction for the whole project, but that’s all. Construction Engineers have pretty huge and detailed requirements, they have huge Gantt charts, with +100pages documents describing how the pavement of neighborhood X should be.
I’m increasingly uncomfortable with using engineering analogies because I don’t know what they actually do instead. For all I know, maybe they actually DO use something exactly like this! Consider how bizarre a lot of CS things would seem from the outside: “imagine if we ran around crashing random servers in production just to see if we’d recover!”
From my admittedly limited experience with large construction projects. Those planning large construction projects create very detailed check lists in the form of gantt charts with everything that depends on other things happening being inputted into the list. They are updated at least once daily, often more so when things go ahead or behind schedule.
Very good for what-if analysis, so when the crane in use breaks and no others are available for two weeks you can see what that will be impacting two months down the line and plan accordingly.
Most processes can be distilled down to check lists and JIRA is just a fancy check list; however without being able to see the wider picture (e.g tree view or gantt chart) you can end up negatively affecting things further down the line that you weren’t aware of while working through your segmented list of tasks. From my experience JIRA forces you to focus on the details and ignore the wider picture and that is something I think this article is attempting to address.
I don’t think that’s the point. You can’t use analogies not in the common knowledge of the reader, otherwise you’ll make the topic even harder to grasp.
You’re right, I missed the point that hwayne was making :)
JIRA has its issues, but this is not a very good summary of them. I’m not sure that being able to visualize every single minute detail of a project should be a goal for any tool. What’s the value add from having a graph of your project and every single one of its dependencies?
Some of the grafs are just incomphrehensible:
Some of them blame cultural issues on tool design:
Some of it posits that teams are using JIRA in a way that I’ve frankly never seen in the wild, has anyone seen this?
Most teams I’ve seen use JIRA to break down projects that have been discussed or documented elsewhere.
It’s not a particularly good article, but enough devs will spontaneously and sympathetically upvote because “fuck jira” that the piece will get increased exposure, Techcrunch will get more ad impressions, his blog and twitter will get more traffic, and so on and so forth.
Precisely. See my comment above. Obviously anyone can post anything they want, but this kind of writing that optimized for clicks and splash isn’t something I feel will make the average developer’s life a better place.
I feel like the author’s primary complaint is against process. Jira is a tool. It’s flexible enough to implement many different processes. You don’t have to have mini-waterfalls. A ticket could have statuses of “To-do”, “In Progress” and “Done” and “In Progress” can be anything you want. Pair programming, test driven, etc. Or you can get detailed and enumerate all the specific steps.
No tool replaces having a good, clear process that people actually stick to.
I will agree that Jira is more focused to lower level, detailed tasking and higher level project goals can benefit from a different tool.
Yeah, this seems to be written by someone largely unfamiliar with Jira. Or familiar with only its use in a single company where it’s poorly managed.
I agree that you shouldn’t use Jira to define your process, but instead to describe and document your process. But I also think that Jira works fine with high-level project goals. Having a ticket type for “Project” or “Epic” that can be used for high-level prioritization seems to work reasonably well where I’ve seen it done. And you can even use (perhaps to the author’s shock) prose to describe the project and its status. Actually attaching work tickets to those project tickets is not required by Jira in any way.
Basically, tickets types can scale up and down, and have different workflows per ticket type (and even per Jira project). If you approach it like a generalized tracking tool, then it’s capable of modelling a huge number of processes, large and small.
Complaining about a tool is an antipattern.
I hate to nitpick because there some good ideas in here but WOW I really hate the title.
This article should have been “Over-using JIRA is an Anti-pattern”.
Sure, it wouldn’t have had the splash this one did, but it’d be accurate.
Kinda tempted now to make an article called “JIRA is anti-pattern” that’s all about how JIRA breaks people’s pattern recognition
I really love the proposed solution, but I doubt it would scale.
To me it’s the exact representation of how to coordinate people on a high level, if you now have 40 people working on a project for 5 years, you’ll find out that a 10 page document to describe everything might not be enough. You’d need way more documentation on what’s the purpose of a feature and how it should work.
This would be a good document to onboard people on the project and keep as a direction for the whole project, but that’s all. Construction Engineers have pretty huge and detailed requirements, they have huge Gantt charts, with +100pages documents describing how the pavement of neighborhood X should be.