4 ms·

Not the person you responded to, but I'll take a swing. In many org, you don't just write a JIRA ticket. You write a ticket. It ends up in the backlog. You are

by RogerL 6y ago

Not the person you responded to, but I'll take a swing. In many org, you don't just write a JIRA ticket. You write a ticket. It ends up in the backlog. You are in the middle of a sprint. you are not allowed to change the sprint. 2 weeks (or whatever) later you have a meeting, where you have to argue for your ticket being next. That probably doesn't result in success, but pretend it does. Then it gets assigned to somebody that essentially knows nothing about it, because developers are interchangable, don't you know? Meanwhile you are stalled because that refactor made sense to do before the ticket you are working on. So you work on that one, don't move it to complete, and get dinged. Or you do it anyway, knowing you will have to do the work a second time once the refactor is done, but hey, you'll get so move multiple tickets to 'ready for test' next sprint or so, so yay, you measure well, can't wait for bonus time! Yes, I just described a horrible process, but pretty much how it goes in most places. The very first thing people forget, and fight strenuously against, is the agile principle "people, not process" To offer the counterpoint, if I am refactoring sw that runs in a flight computer or something, even more process is needed, because you need to test extensively before releasing code that can kill someone. That check in can cost hundreds of thousands of dollars if you touched something that is now going to have to go through lengthy QA. It just depends on where you work, and the cost of bugs vs rapid response to problems/requests. In my experience orgs try to build a workflow that would suit the space shuttle when the product is, well, less important and serious.

ryandrake 6y ago
Great comment, and I'm glad you replied with these examples. The problems you describe are corporate software development process problems and not problems with Jira or bug trackers in general. It's a dysfunctional company welding their dysfunction onto Jira, and Jira gets the bad rap. Most of the time when people on HN complain "I hate Jira!" what they really mean is "I hate my company's inflexible software development process." Jira just happens to be the UI surface that this horrible process is exposed through, so naturally they take their hatred out on Jira. Here are a few process examples I've seen (taken from real companies): Company A: Bug tracker contains a handful of bugs and features, but you can pretty much commit whatever you want, whenever you want, without a ticket. Lots of work, major and minor, being done totally untracked through anything outside of git log. Company B: Everything you touch requires a ticket, full stop. Ticket creation and assignment is a laborious process as you described in your comment. Sprint scope enforced ruthlessly. Sudden changes in scope and dependencies must wait until the next sprint. Company C: Strictly one ticket per commit. But if you need to make the change, just create the ticket, document your change there, and close the ticket. No big deal. If you're not working on the right stuff, your eng lead or project manager will notice when they browse through the assigned and closed tickets. Company D: Just like Company C, but without the "one ticket per commit" rule. You could commit whatever you wanted as long as you could point to a ticket that described what it was for, and you could use that ticket over and over and close it when you were ultimately done. Company A was total chaos, and we constantly missed deadlines and chased quality problems. Only eng really had a clue about what work was done, in progress, or in the backlog. The eng leads simply kept it all in their heads and documenting/communicating was an afterthought. Company B was frustrating and bureaucratic, but we at least managed to ship most of the scope on time and with reasonable quality. Not great eng morale but management was happy with output. Company C was the best. Really easy to derive project status by just looking at the bug tracker. The "create a ticket" habit was drilled in to you during orientation and was just not seen as a big deal. Company D was kind of a mixed bag. Eng loved it, but it was hard for the managers to track progress because you always had all these "mega-bugs" open listing commit after commit after commit, and there was no indication of % completion. I didn't mention the actual bug tracker for any of these companies, because it really doesn't matter. You can use any bug tracker to support any of those processes. There is nothing Jira-specific here.
- devdas 6y ago
  The problem with company C style work is when you do really small incremental changes. I have had 40+ commits for a single issue, being very gradually rolled out. The time taken to manage tickets in that case would easily have exceeded the time spent on the task itself.
  - SideburnsOfDoom 6y ago
    This is correct. "one JIRA ticket = one git Pull Request" is not a good system even when the work can be rolled out in one go, since it encourages PRs that are overly large, long-lived branches and late integration with merge issues. Rather encourage having an idea of where you're headed with the chain of commits, and review and merge a sequence of smaller steps, and ideally validate each of them by deploying to production. This is easier to review, easier to merge and less risk to deploy. If JIRA is not a good fit to this model, too bad, that's JIRAs problem. Don't make you dev process worse to appease JIRA.

by RogerL 6y ago

ryandrake 6y ago

Great comment, and I'm glad you replied with these examples. The problems you describe are corporate software development process problems and not problems with Jira or bug trackers in general. It's a dysfunctional company welding their dysfunction onto Jira, and Jira gets the bad rap. Most of the time when people on HN complain "I hate Jira!" what they really mean is "I hate my company's inflexible software development process." Jira just happens to be the UI surface that this horrible process is exposed through, so naturally they take their hatred out on Jira. Here are a few process examples I've seen (taken from real companies): Company A: Bug tracker contains a handful of bugs and features, but you can pretty much commit whatever you want, whenever you want, without a ticket. Lots of work, major and minor, being done totally untracked through anything outside of git log. Company B: Everything you touch requires a ticket, full stop. Ticket creation and assignment is a laborious process as you described in your comment. Sprint scope enforced ruthlessly. Sudden changes in scope and dependencies must wait until the next sprint. Company C: Strictly one ticket per commit. But if you need to make the change, just create the ticket, document your change there, and close the ticket. No big deal. If you're not working on the right stuff, your eng lead or project manager will notice when they browse through the assigned and closed tickets. Company D: Just like Company C, but without the "one ticket per commit" rule. You could commit whatever you wanted as long as you could point to a ticket that described what it was for, and you could use that ticket over and over and close it when you were ultimately done. Company A was total chaos, and we constantly missed deadlines and chased quality problems. Only eng really had a clue about what work was done, in progress, or in the backlog. The eng leads simply kept it all in their heads and documenting/communicating was an afterthought. Company B was frustrating and bureaucratic, but we at least managed to ship most of the scope on time and with reasonable quality. Not great eng morale but management was happy with output. Company C was the best. Really easy to derive project status by just looking at the bug tracker. The "create a ticket" habit was drilled in to you during orientation and was just not seen as a big deal. Company D was kind of a mixed bag. Eng loved it, but it was hard for the managers to track progress because you always had all these "mega-bugs" open listing commit after commit after commit, and there was no indication of % completion. I didn't mention the actual bug tracker for any of these companies, because it really doesn't matter. You can use any bug tracker to support any of those processes. There is nothing Jira-specific here.

devdas 6y ago
The problem with company C style work is when you do really small incremental changes. I have had 40+ commits for a single issue, being very gradually rolled out. The time taken to manage tickets in that case would easily have exceeded the time spent on the task itself.
- SideburnsOfDoom 6y ago
  This is correct. "one JIRA ticket = one git Pull Request" is not a good system even when the work can be rolled out in one go, since it encourages PRs that are overly large, long-lived branches and late integration with merge issues. Rather encourage having an idea of where you're headed with the chain of commits, and review and merge a sequence of smaller steps, and ideally validate each of them by deploying to production. This is easier to review, easier to merge and less risk to deploy. If JIRA is not a good fit to this model, too bad, that's JIRAs problem. Don't make you dev process worse to appease JIRA.