3 ms·

You find a typo on the website. Instead of pull, switch the "i" to an "o", commit, push which takes 30 seconds you have: 1.) Open web browser 2.) go to your J

by malyk 14y ago

You find a typo on the website. Instead of pull, switch the "i" to an "o", commit, push which takes 30 seconds you have: 1.) Open web browser 2.) go to your JIRA url 3.) enter your username/password 4.) enter your password again because you mis-typed it 5.) find the project page for that particular project and wait for it to load 6.) find the place where you add new tickets and wait for that to load 7.) type in a bunch of bullshit on a long form and submit that 8.) Hopefully you get to assign the bug to yourself. God forbid you have to have a PM do the actual assignment! 9.) pull, make the change, push 10.) go back into jira and open the ticket 11.) write a description of how you fixed the "bug" 12.) close the ticket Ok, so that's the worst case, but the only real work you should /need/ to do is #9. The whole process of creating/assigning/closing the ticket probably only takes a minute or two, but it's probably unnecessary in most software systems and, over time, adds a ton of frustration where none is needed.

michaelochurch 14y ago
Right. That's the kind of nonsense that managers are OK with because they think that it's more important to monitor performance on an hour-by-hour basis than let you get into flow and actually perform.
prof_hobart 14y ago
I like the way that the stuff you think you need is rolled up into a single "pull, make the change, push" yet the stuff you don't see any value in is spread out into having to open the application, go to the site, get things wrong etc. If it's browser-based, could you not simply have a browser link to to "Add ticket" to replace most of the first 6 steps? Also, "type in a bunch of bullshit on a long form and submit that" - like I say, I don't know Jira, but I doubt that it forces you to type a long bit of bullshit. I'm sure that "correct spelling" would do. And I'd also expect that you'd be doing something similar in your source control system so that someone looking through the code at some point in the future can see why (or when) the particular change was made. And how often do you make this kind of change as opposed to actually working on bugs/improvements that are coming in through JIRA? I'm sure that there are occasions when your tool gets in the way of getting the work done, but from your description I'm not sure it sounds like it's a major inconvenience most of the time, which needs to be balanced against the benefit you get from having a centralised place to track, prioritise and allocate the work.
- malyk 14y ago
  Of course, it was a bit of hyperbole. It's meant as an illustration. I agree that there should be a centralized place to track, prioritize, and allocate work. But the comment I was responding to was about having a ticket for every code change, which is absurd if you take it to the extreme. If I'm working on feature X, but come across a typo, do I have to have a ticket to fix the typo or can I just fix it as I go along? Again, we are taking things to the extreme in the examples. In a sane workflow, someone prioritizes a list of tasks, someone (hopefully the group) divides up the tasks, and then we work on them one at a time. All of that is in a central place and developers generally don't have a problem tracking like that. But what about the case where you find a bug (especially a small one)? In larger teams you probably want to indicate that you fixed something so that the testing team can have something to verify against. In a small team you just fix it and go on without the overhead of making a ticket for every one of those you discover. An example from today. I just came across some code that was "unless @blah.blank?", but it should probably be turned around to "if @blah.present?", so I made the change. If I had to write a ticket for that I would quickly want to strangle someone. And that's what the original comment I responded to seemed to be asking about.
  - prof_hobart 14y ago
    The problem is that I've seen far too many examples of people fixing a "clearly a bug" that either turns out to be entirely correct for a reason the developer wasn't aware of, or even when it is a bug it breaks something down the line that depended on the bug being there (e.g. for a spelling mistake, it turns out some other application was screen-scraping it and depended on that spelling mistake to identify a given page). > In larger teams you probably want to indicate that you fixed something so that the testing team can have something to verify against. In a small team you just fix it and go on without the overhead of making a ticket for every one of those you discover. I think you may have hit the nail on the head there. "to start writing code, you need a Jira ticket" isn't a bad process per se. It's a bad process if you're working on certain types of project e..g. in a small team where everyone intimately knows the codebase and all of its uses. And I think that's what the article was about - blindly applying a process designed for one type of development to an entirely different type.
colanderman 14y ago
You forgot: 9a.) Make a Crucible review 9b.) Refresh a few times because Crucible isn't loading correctly 9c.) Figure out who to invite to the review 9d.) Wait 3 days until the PM notices the review and signs off on it 9e.) Close the review 9f.) Wait another day because the tools team decided they'd upgrade all the Atlassian tools today Is this shit really common? I thought it was just where I worked.

by malyk 14y ago

michaelochurch 14y ago

Right. That's the kind of nonsense that managers are OK with because they think that it's more important to monitor performance on an hour-by-hour basis than let you get into flow and actually perform.

prof_hobart 14y ago

I like the way that the stuff you think you need is rolled up into a single "pull, make the change, push" yet the stuff you don't see any value in is spread out into having to open the application, go to the site, get things wrong etc. If it's browser-based, could you not simply have a browser link to to "Add ticket" to replace most of the first 6 steps? Also, "type in a bunch of bullshit on a long form and submit that" - like I say, I don't know Jira, but I doubt that it forces you to type a long bit of bullshit. I'm sure that "correct spelling" would do. And I'd also expect that you'd be doing something similar in your source control system so that someone looking through the code at some point in the future can see why (or when) the particular change was made. And how often do you make this kind of change as opposed to actually working on bugs/improvements that are coming in through JIRA? I'm sure that there are occasions when your tool gets in the way of getting the work done, but from your description I'm not sure it sounds like it's a major inconvenience most of the time, which needs to be balanced against the benefit you get from having a centralised place to track, prioritise and allocate the work.

malyk 14y ago
Of course, it was a bit of hyperbole. It's meant as an illustration. I agree that there should be a centralized place to track, prioritize, and allocate work. But the comment I was responding to was about having a ticket for every code change, which is absurd if you take it to the extreme. If I'm working on feature X, but come across a typo, do I have to have a ticket to fix the typo or can I just fix it as I go along? Again, we are taking things to the extreme in the examples. In a sane workflow, someone prioritizes a list of tasks, someone (hopefully the group) divides up the tasks, and then we work on them one at a time. All of that is in a central place and developers generally don't have a problem tracking like that. But what about the case where you find a bug (especially a small one)? In larger teams you probably want to indicate that you fixed something so that the testing team can have something to verify against. In a small team you just fix it and go on without the overhead of making a ticket for every one of those you discover. An example from today. I just came across some code that was "unless @blah.blank?", but it should probably be turned around to "if @blah.present?", so I made the change. If I had to write a ticket for that I would quickly want to strangle someone. And that's what the original comment I responded to seemed to be asking about.
- prof_hobart 14y ago
  The problem is that I've seen far too many examples of people fixing a "clearly a bug" that either turns out to be entirely correct for a reason the developer wasn't aware of, or even when it is a bug it breaks something down the line that depended on the bug being there (e.g. for a spelling mistake, it turns out some other application was screen-scraping it and depended on that spelling mistake to identify a given page). > In larger teams you probably want to indicate that you fixed something so that the testing team can have something to verify against. In a small team you just fix it and go on without the overhead of making a ticket for every one of those you discover. I think you may have hit the nail on the head there. "to start writing code, you need a Jira ticket" isn't a bad process per se. It's a bad process if you're working on certain types of project e..g. in a small team where everyone intimately knows the codebase and all of its uses. And I think that's what the article was about - blindly applying a process designed for one type of development to an entirely different type.

colanderman 14y ago

You forgot: 9a.) Make a Crucible review 9b.) Refresh a few times because Crucible isn't loading correctly 9c.) Figure out who to invite to the review 9d.) Wait 3 days until the PM notices the review and signs off on it 9e.) Close the review 9f.) Wait another day because the tools team decided they'd upgrade all the Atlassian tools today Is this shit really common? I thought it was just where I worked.