11 ms·

I mean, thats pretty normal for any stage tech organization. The question is, who gets the right to create a jira ticket? Maybe you can do it, or just one othe

by mr-ron 4y ago

I mean, thats pretty normal for any stage tech organization. The question is, who gets the right to create a jira ticket? Maybe you can do it, or just one other person. Thats not a big limitation at all to moving quick. Edit because this is causing a stir: Engineers within teams should have the right to create tickets themselves. Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds. Updating documentation may require a pull request. Controls (SOC compliance) may require that work is tracked to tickets. The core questions I have is, who can create the tickets, and how detailed do they need to be?

notyourwork 4y ago
What is normal about this? Engineers should be empowered with ownership. Adding. friction or barriers to enabling engineers to make what they own better is backwards and counter productive at best. At worst, it discourages proactive willingness to make an improvement.
- mr-ron 4y ago
  What is normal about this that Ive seen is work and tickets is often written into controls that are required for things like SOC compliance. And documentation often requires a pull request. And again read what I said, that engineers can and could be empowered to make these tickets, which can be minimal at best. Done right, its not a limitation at all, and instead adds accountability.
  - eropple 4y ago
    > Done right, its not a limitation at all Context switches are limiters, IME. Smash somebody's stack and you've made them useless for half an hour.
    - mr-ron 4y ago
      This is why tickets can be used to protect the engineering team. You dont want people ad-hoc adding scope, or interrupting work for engineers. You want engineers to have focus time, on a clear actionable item, that is set up for success, and will add value. Allowing engineers to work on whatever they want, or change scope on what they want, without saying 'why', can end up creating a lot of wasted work.
      - eropple 4y ago
        Tickets can, theoretically, be used to protect a development team. I agree with you there. But they usually aren't, and most folks are living in the land of what-is, not what-can-be.
        mr-ron 4y ago
        Yes I agree and thats why Scrum / Agile gets a bad rap around here.
  - knightofmars 4y ago
    "...things like SOC compliance." This is an important point. If you work in a regulated industry or work with software used in a regulated industry you need a "paper trail". Having to document and follow a process is often frustrating to people who work or have worked in industries that don't require it. That said, a poorly implemented process in a regulated industry is even worse. As you're overloading teams with busy work and likely still failing to meet the requirements of the regulations you're following. Regulated software is not a place to "move fast and break things" that's what prototypes that never see the light of production are for. Build it without regulation to figure out how to do it and then build it again following the documentation process. It may sound odd but having a second chance to correct errors of assumption from the first time around is quite valuable, buying information when done right is a great tool.
    - mr-ron 4y ago
      SOC compliance is indeed a beast. I have my own theories on how valuable this benchmarks REALLY is, but if teams are in a financial org, it is super common to have controls that have the potential to really hamstring teams. Which is doubly important to really understand the vision of agile / scrum, and not just follow the ceremonies by the book.
      - sanderjd 4y ago
        Could you point me to where in the regulations it says you must have a duplicate paper trail? A PR is already a paper trail...
        rleigh 4y ago
        A PR is most emphatically *not* a paper trail. It's recording a software change, who made it, and when. That isn't even close to the bare minimum for some of the regulatory requirements. You're coming to this with the perspective of a typical software developer. I can sympathise greatly. But the regulations aren't about software development. They are about risk management and product quality, and putting in place processes to ensure projects deliver solutions which are safe and robust, due to having the appropriate controls in place. This isn't just about the software implementation. It goes all the way up to the specifications, designs and requirements and it requires testing and validation work at every level. I have only in the last few years been working in such an environment. It was eye-opening. Compared with the free-for-all which is most software development, this is actually about engineering robust systems, in a very systematic and rigorous way. That does include some overhead in the processes surrounding the development work, but it's there for a very good reason.
  - ozim 4y ago
    Even not SOC compliance just liability of a company. If stuff fails and company gets sued - they will have to prove that they "follow industry standards" because if they don't follow industry standards then all kinds of bad stuff can follow. IF you get ransom-ware and have an insurance - see the exclusions - you have to have EDR software on each server otherwise insurance won't pay. Not following industry standards in terms of code - the same no insurance company will pay if they catch you on just doing stuff. So running a business all kind of BS and it is not optional and just slinging out code is not enough.
- nix0n 4y ago
  If it's in a repo, it's normal to need a PR to change it. And, it's normal for a PR to need a ticket. Alternatives to creating a new ticket could be: 1) Link to the ticket number that was used, for creating whatever you're documenting now. Use the "blame" report. 2) Link it to a catch-all ticket for documentation or code quality. Look in your ticket system for a low ticket number, with recent activity. If this doesn't already exist, and you really do need to make a new ticket, write it as generally as possible to enable this style of reuse.
  - eropple 4y ago
    > If it's in a repo, it's normal to need a PR to change it. And, it's normal for a PR to need a ticket. In my experience, the former is true but the latter is extremely not. Tickets are for tracking concerns for stakeholders. A documentation fix, to use the example at hand, is an ad-hoc improvement for customers/consumers and should have as little in the way of it as possible.
    - mr-ron 4y ago
      Those ad-hoc doc updates are the exception vs the norm. It is also common to have controls in github, where its required for a jira ticket to be attached to a PR. In that situation. Its literally impossible to merge into the codebase without a ticket. Again it comes down to 'who can create the ticket' and 'what is the required scope of the ticket'
      - est31 4y ago
        They are exceptional the harder it is to make them, and the result is documentation full of minor grammar mistakes or unclear things. As an example for where it works great, I have made a small documentation fix PR to the Rust standard library 2 days ago and I didn't have to create a github issue for it or anything (but I had to notify a maintainer to review it because the PR fell through the cracks it seems). That maintainer told me they have reviewed 5 other similar pull requests that day. Over time, you get a really nice code base that way.
whynotmaybe 4y ago
You find it normal that you need a Jira ticket to update documentation? If while reading a document, you find a mistake, instead of changing it, the normal reflex is to create a Jira ticket?
- mr-ron 4y ago
  It depends on the documentation. Is it within a repo? Does it require a pull request? Is it a quick edit, or is this a multi hour effort that is redoing the scope?
- timmytokyo 4y ago
  I find this whole back-and-forth fascinating, because it mirrors my experiences in the workplace. There are some people who really like process around everything an engineer does, and some people who really don't like it. They're almost two distinct personality types, and it's virtually impossible to get them to agree because it's like asking someone to change their personality. I happen to be one of the types who dislikes heavy process-oriented project management, and reading mr-ron's responses is admittedly making my blood boil. But I bet he reads some of the responses to his remarks and probably has similar reactions. Some people thrive with heavy process, and some people wither. Some people thrive with light-weight process, and some people wither. I don't know how to structure an organization to support both types of people in it, but it's not an easy problem to solve. That's why there are so many project management methodologies, with new ones popping up every few years and then inevitably disappearing in favor of something new and better.
  - mr-ron 4y ago
    Im not sure why you are describing my example of PRs needing tickets to be 'heavy process'. Especially since Im pushing for engineers being able to create quick ad-hoc tickets within 30 seconds.
    - timmytokyo 4y ago
      It feels heavy to me, because you're asking for a process gate to be put in front of something that is so trivial. It feels utterly unnecessary and demotivating. If I see a minor problem in the documentation and decide to correct it, now I have to go through an extra step of creating a JIRA ticket describing the minor problem I'm trying to solve, doing the correction, updating the JIRA ticket status, and possibly monitoring the ticket for future issues. It's. all. so. bureaucratic. And sadly it will probably lead me to thinking the fix is not worth my time. Instead of trying to convince everyone that they should feel the way you do, maybe try to understand why others feel the way they do.
azemetre 4y ago
I disagree with it moving quickly, all it does is encourage me to not update documentation and not actively improve the code in other ways due to inane bureaucracy. And surprised surprise, no on else on the team wants to document anything either; people get burnt out because they have no autonomy and just leave. All is good tho! We followed the process and that's the only thing that matters. I wonder what the corporate equivalent to "I was just following orders" is?
- mr-ron 4y ago
  If an engineer can create a ticket and work on it, thats not reducing autonomy. Thats adding accountability. If documentation requires a pull request / merge to update, often you have set controls that require a jira ticket. Its super common to not allow engineers to make solo commits without a pull request. If an engineer sees the creation of a jira ticket as a limitation, or if they are not empowered to create their own tickets, then Id agree its a problem.
  - carlisle_ 4y ago
    Is creating the ticket really adding value to the engineering process? In your example you already have the engineer making a PR (presumably peer reviewed) and a commit, what’s the ticket really needed for?
    - mr-ron 4y ago
      It can add value if done right. Just as you typically want to make a design doc / rfc before working on a project, you often want to describe what you are doing before you do it. This can protect the engineer / team against scope creep, as well as determine the context of why work was done when you may need to understand more context (in the case of a bug for example). Also it increases accountability and transparency. It is common that teams want to know what other engineers are working on and why.
      - carlisle_ 4y ago
RayFrankenstein 4y ago
Cute Agilist gaslighting about not needing a ticket because that’s “asking for permission” and it’s supposed to be implicitly bundled into feature work.
ianbutler 4y ago
Is it? I've never needed a ticket to make off the cuff improvements. A PR and a review from other engs to make sure they agree, certainly, but a ticket for that seems like a certain degree of dev micromanagement/big brother/power trip for highly paid and skilled professionals.
- Rapzid 4y ago
  At my previous gig we reduced the friction for doc contributions to just a PR but with no review requirement; if the contributor felt the need for feedback or review they would seek it, otherwise just merge the changes.
sanderjd 4y ago
That's a stupid compliance requirement, unless documentation changes aren't themselves versioned (which they should be). You don't need to track the exact same thing in two separate places.
lupire 4y ago
If it's so important to have a ticket, the patch submission pipeline should create one automatically.
Too 4y ago
”Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds” This type of placeholder-documentation is literally the WORST type of tracking you can have. And a sign that everybody in your company forgot the reason why this type of traceability was implemented in the first place. If I review a PR that links to a Jira ticket that says absolutely nothing except “update documentation”. What’s the whole point?! What’s worse is when people see a link to a Jira as an excuse to write bad commit messages. I would much rather read a commit message detailing out the background and rationale of the change, rather than a nonsense commit message linking to another nonsense kpi-chasing Jira ticket. PRs are code reviewed anyway so it’s not like you have a bonanza of unknown changes being pushed left and right. Code reviews not only catches coding bugs but also accountability within the team, eg “why are you refactoring something that works, when our backlog has 100 other more important things to do.”

by mr-ron 4y ago

notyourwork 4y ago

What is normal about this? Engineers should be empowered with ownership. Adding. friction or barriers to enabling engineers to make what they own better is backwards and counter productive at best. At worst, it discourages proactive willingness to make an improvement.

mr-ron 4y ago
What is normal about this that Ive seen is work and tickets is often written into controls that are required for things like SOC compliance. And documentation often requires a pull request. And again read what I said, that engineers can and could be empowered to make these tickets, which can be minimal at best. Done right, its not a limitation at all, and instead adds accountability.
- eropple 4y ago
  > Done right, its not a limitation at all Context switches are limiters, IME. Smash somebody's stack and you've made them useless for half an hour.
  - mr-ron 4y ago
    This is why tickets can be used to protect the engineering team. You dont want people ad-hoc adding scope, or interrupting work for engineers. You want engineers to have focus time, on a clear actionable item, that is set up for success, and will add value. Allowing engineers to work on whatever they want, or change scope on what they want, without saying 'why', can end up creating a lot of wasted work.
    - eropple 4y ago
      Tickets can, theoretically, be used to protect a development team. I agree with you there. But they usually aren't, and most folks are living in the land of what-is, not what-can-be.
      - mr-ron 4y ago
        Yes I agree and thats why Scrum / Agile gets a bad rap around here.
- knightofmars 4y ago
  "...things like SOC compliance." This is an important point. If you work in a regulated industry or work with software used in a regulated industry you need a "paper trail". Having to document and follow a process is often frustrating to people who work or have worked in industries that don't require it. That said, a poorly implemented process in a regulated industry is even worse. As you're overloading teams with busy work and likely still failing to meet the requirements of the regulations you're following. Regulated software is not a place to "move fast and break things" that's what prototypes that never see the light of production are for. Build it without regulation to figure out how to do it and then build it again following the documentation process. It may sound odd but having a second chance to correct errors of assumption from the first time around is quite valuable, buying information when done right is a great tool.
  - mr-ron 4y ago
    SOC compliance is indeed a beast. I have my own theories on how valuable this benchmarks REALLY is, but if teams are in a financial org, it is super common to have controls that have the potential to really hamstring teams. Which is doubly important to really understand the vision of agile / scrum, and not just follow the ceremonies by the book.
    - sanderjd 4y ago
      Could you point me to where in the regulations it says you must have a duplicate paper trail? A PR is already a paper trail...
      - rleigh 4y ago
        A PR is most emphatically *not* a paper trail. It's recording a software change, who made it, and when. That isn't even close to the bare minimum for some of the regulatory requirements. You're coming to this with the perspective of a typical software developer. I can sympathise greatly. But the regulations aren't about software development. They are about risk management and product quality, and putting in place processes to ensure projects deliver solutions which are safe and robust, due to having the appropriate controls in place. This isn't just about the software implementation. It goes all the way up to the specifications, designs and requirements and it requires testing and validation work at every level. I have only in the last few years been working in such an environment. It was eye-opening. Compared with the free-for-all which is most software development, this is actually about engineering robust systems, in a very systematic and rigorous way. That does include some overhead in the processes surrounding the development work, but it's there for a very good reason.
- ozim 4y ago
  Even not SOC compliance just liability of a company. If stuff fails and company gets sued - they will have to prove that they "follow industry standards" because if they don't follow industry standards then all kinds of bad stuff can follow. IF you get ransom-ware and have an insurance - see the exclusions - you have to have EDR software on each server otherwise insurance won't pay. Not following industry standards in terms of code - the same no insurance company will pay if they catch you on just doing stuff. So running a business all kind of BS and it is not optional and just slinging out code is not enough.
nix0n 4y ago
If it's in a repo, it's normal to need a PR to change it. And, it's normal for a PR to need a ticket. Alternatives to creating a new ticket could be: 1) Link to the ticket number that was used, for creating whatever you're documenting now. Use the "blame" report. 2) Link it to a catch-all ticket for documentation or code quality. Look in your ticket system for a low ticket number, with recent activity. If this doesn't already exist, and you really do need to make a new ticket, write it as generally as possible to enable this style of reuse.
- eropple 4y ago
  > If it's in a repo, it's normal to need a PR to change it. And, it's normal for a PR to need a ticket. In my experience, the former is true but the latter is extremely not. Tickets are for tracking concerns for stakeholders. A documentation fix, to use the example at hand, is an ad-hoc improvement for customers/consumers and should have as little in the way of it as possible.
  - mr-ron 4y ago
    Those ad-hoc doc updates are the exception vs the norm. It is also common to have controls in github, where its required for a jira ticket to be attached to a PR. In that situation. Its literally impossible to merge into the codebase without a ticket. Again it comes down to 'who can create the ticket' and 'what is the required scope of the ticket'
    - est31 4y ago
      They are exceptional the harder it is to make them, and the result is documentation full of minor grammar mistakes or unclear things. As an example for where it works great, I have made a small documentation fix PR to the Rust standard library 2 days ago and I didn't have to create a github issue for it or anything (but I had to notify a maintainer to review it because the PR fell through the cracks it seems). That maintainer told me they have reviewed 5 other similar pull requests that day. Over time, you get a really nice code base that way.

whynotmaybe 4y ago

You find it normal that you need a Jira ticket to update documentation? If while reading a document, you find a mistake, instead of changing it, the normal reflex is to create a Jira ticket?

mr-ron 4y ago
It depends on the documentation. Is it within a repo? Does it require a pull request? Is it a quick edit, or is this a multi hour effort that is redoing the scope?
timmytokyo 4y ago
I find this whole back-and-forth fascinating, because it mirrors my experiences in the workplace. There are some people who really like process around everything an engineer does, and some people who really don't like it. They're almost two distinct personality types, and it's virtually impossible to get them to agree because it's like asking someone to change their personality. I happen to be one of the types who dislikes heavy process-oriented project management, and reading mr-ron's responses is admittedly making my blood boil. But I bet he reads some of the responses to his remarks and probably has similar reactions. Some people thrive with heavy process, and some people wither. Some people thrive with light-weight process, and some people wither. I don't know how to structure an organization to support both types of people in it, but it's not an easy problem to solve. That's why there are so many project management methodologies, with new ones popping up every few years and then inevitably disappearing in favor of something new and better.
- mr-ron 4y ago
  Im not sure why you are describing my example of PRs needing tickets to be 'heavy process'. Especially since Im pushing for engineers being able to create quick ad-hoc tickets within 30 seconds.
  - timmytokyo 4y ago
    It feels heavy to me, because you're asking for a process gate to be put in front of something that is so trivial. It feels utterly unnecessary and demotivating. If I see a minor problem in the documentation and decide to correct it, now I have to go through an extra step of creating a JIRA ticket describing the minor problem I'm trying to solve, doing the correction, updating the JIRA ticket status, and possibly monitoring the ticket for future issues. It's. all. so. bureaucratic. And sadly it will probably lead me to thinking the fix is not worth my time. Instead of trying to convince everyone that they should feel the way you do, maybe try to understand why others feel the way they do.

azemetre 4y ago

I disagree with it moving quickly, all it does is encourage me to not update documentation and not actively improve the code in other ways due to inane bureaucracy. And surprised surprise, no on else on the team wants to document anything either; people get burnt out because they have no autonomy and just leave. All is good tho! We followed the process and that's the only thing that matters. I wonder what the corporate equivalent to "I was just following orders" is?

mr-ron 4y ago
If an engineer can create a ticket and work on it, thats not reducing autonomy. Thats adding accountability. If documentation requires a pull request / merge to update, often you have set controls that require a jira ticket. Its super common to not allow engineers to make solo commits without a pull request. If an engineer sees the creation of a jira ticket as a limitation, or if they are not empowered to create their own tickets, then Id agree its a problem.
- carlisle_ 4y ago
  Is creating the ticket really adding value to the engineering process? In your example you already have the engineer making a PR (presumably peer reviewed) and a commit, what’s the ticket really needed for?
  - mr-ron 4y ago
    It can add value if done right. Just as you typically want to make a design doc / rfc before working on a project, you often want to describe what you are doing before you do it. This can protect the engineer / team against scope creep, as well as determine the context of why work was done when you may need to understand more context (in the case of a bug for example). Also it increases accountability and transparency. It is common that teams want to know what other engineers are working on and why.
    - carlisle_ 4y ago

RayFrankenstein 4y ago

Cute Agilist gaslighting about not needing a ticket because that’s “asking for permission” and it’s supposed to be implicitly bundled into feature work.

ianbutler 4y ago

Is it? I've never needed a ticket to make off the cuff improvements. A PR and a review from other engs to make sure they agree, certainly, but a ticket for that seems like a certain degree of dev micromanagement/big brother/power trip for highly paid and skilled professionals.

Rapzid 4y ago
At my previous gig we reduced the friction for doc contributions to just a PR but with no review requirement; if the contributor felt the need for feedback or review they would seek it, otherwise just merge the changes.

sanderjd 4y ago

That's a stupid compliance requirement, unless documentation changes aren't themselves versioned (which they should be). You don't need to track the exact same thing in two separate places.

lupire 4y ago

If it's so important to have a ticket, the patch submission pipeline should create one automatically.

Too 4y ago

”Tickets should be minimal depending on the task. Creating a ticket that says 'update documentation' may take 10 seconds” This type of placeholder-documentation is literally the WORST type of tracking you can have. And a sign that everybody in your company forgot the reason why this type of traceability was implemented in the first place. If I review a PR that links to a Jira ticket that says absolutely nothing except “update documentation”. What’s the whole point?! What’s worse is when people see a link to a Jira as an excuse to write bad commit messages. I would much rather read a commit message detailing out the background and rationale of the change, rather than a nonsense commit message linking to another nonsense kpi-chasing Jira ticket. PRs are code reviewed anyway so it’s not like you have a bonanza of unknown changes being pushed left and right. Code reviews not only catches coding bugs but also accountability within the team, eg “why are you refactoring something that works, when our backlog has 100 other more important things to do.”