3 ms·

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

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
Yes, where I work, we really do have to type a long bit of bullshit. At least seven mostly-meaningless fields all need to be filled out or the form will not submit. Worse, several of the fields are drop-down boxes with dozens of entries. Half the time I just click random shit because I don't care and no-one else does.
- prof_hobart 14y ago
  That bit sounds pointless, but I'm guessing that it's not a core part of Jira?
  - colanderman 14y ago
    I'm hoping it's not, but it's what we're presented with.

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

Yes, where I work, we really do have to type a long bit of bullshit. At least seven mostly-meaningless fields all need to be filled out or the form will not submit. Worse, several of the fields are drop-down boxes with dozens of entries. Half the time I just click random shit because I don't care and no-one else does.

prof_hobart 14y ago
That bit sounds pointless, but I'm guessing that it's not a core part of Jira?
- colanderman 14y ago
  I'm hoping it's not, but it's what we're presented with.