5 ms·

You know what’s worse than having to work with JIRA/Confluence/Bit Bucket, and such? Working with people who keep changing systems every 6-12 months. A crappy s

You know what’s worse than having to work with JIRA/Confluence/Bit Bucket, and such? Working with people who keep changing systems every 6-12 months. A crappy system used fully is better than system surfing to find the Holy Grail™.

rad_gruchalski 6y ago
So, like jira every couple of months? Festures removed, ui changed...
- LifeLiverTransp 6y ago
  Braile is the new flat UI - you will love it once, you give this UX a try
dijit 6y ago
Man, I’d agree with you if my experiences with these tools wasn’t _so bad_. The current implementation of jira and confluence I’m using is worse than having _no_ ticket tracking and documentation system. Because if it didn’t exist there would be the impetus to implement something. But we just kinda barely limp by with what we have. It’s so barely functional that people actively avoid using it. I’m fully aware that the company is to blame and not necessarily atlassian though, as we have a number of plugins and random custom fields. One of the most dangerous things about jira is that it tries to be everything to everyone and people get carried away in the customisation believing they need it. It slows everything to a crawl and leaves you inundated with mandatory fields and a nightmare of matching stories with sprints and estimations in order to bring a bloody task in. Life was better with rt and mediawiki.
- JoshuaDavid 6y ago
  I think you're underestimating how bad the "something" people can come up with is. Think "weekly status reports to describe how you're doing on fixing a problem that was described through email, or an in-person meeting with someone, or a phone call, and never entered into a ticketing system at all". Also the mandatory fields are definitely a per-organization thing. At my org we have I think 3 mandatory fields, which are the project the ticket goes under, the title, and the description. In many cases, "migrating" from JIRA to JIRA but 90% of the features are disabled would probably be an improvement.
  - stjohnswarts 6y ago
    If you don't have scripts that will fetch all your parameters and just have to fill in a couple of fields then you're doing it wrong.
    - JoshuaDavid 6y ago
      I do in fact have such scripts :). Also to automatically tag my git commits with the ticket, transition the jira issues appropriately when the relevant things happen with those branches or pull requests, etc. I don't actually interact with JIRA-the-application all that much these days, but in the rare cases when I do it's because I'm doing something non-trivial, and in those cases the UI seems relatively straightforward. ... I suppose that might be the main difference between people who hate JIRA and people who find it a little bit clunky but generally acceptable: people who mostly have the baseline stuff happen automatically are fine with it, and people who spend a lot of time interacting with the web frontend in repetitive ways hate it.
    - dijit 6y ago
      Uh... I’m having trouble envisioning this, do you have any examples? I ended up forcing my slack bot to issue POSTs to Jiras API out of frustration.
      - JoshuaDavid 6y ago
        Yes, exactly that. Basically wire up very simple commands with curl and jq that do the transitions you need, pulling data from other rest apis as necessary. The two workhorses of my integration are two methods named jira_get and jira_post. function jira_get { ENDPOINT="$1" PAYLOAD="$2" URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT" QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')" curl \ --silent \ --request "GET" \ --header "Content-Type: application/json" \ --user "$JIRA_USER:$JIRA_TOKEN" \ "$URL?$QUERY_STRING"; } function jira_post { ENDPOINT="$1" PAYLOAD="$2" URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT" QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')" curl \ --silent \ --request "POST" \ --user "$JIRA_USER:$JIRA_TOKEN" \ --header "Content-Type: application/json" \ "$URL" \ --data "$PAYLOAD"; } Then if you want to get the available transitions, and required fields for those transitions, you can do ISSUE=PRJ-1234 ISSUE_JSON="$(jira_get "issue/$ISSUE/transitions" '{"expand":"transitions.fields"}' TRANSITION_NAMES="$(echo "$ISSUE_JSON" | jq '.transitions[].name')" and then given the transition in question, you can look at the fields required for the transition, and figure out where you get the data that goes in those fields normally. Any time the data that goes in those fields is obtained through a rote process, you automate that process, and then prompt for any fields you can't get in an automated fashion (e.g. "signed off by" you can fetch the reviewer names from the github api for the associated pull request). But yeah, a slack bot that issues requests to the JIRA api is a perfectly workable solution, and I think you'd be surprised at how much of a quality of life improvement you'll get by continuing to add capabilities to it that reflect your specific workflow.
- pc86 6y ago
  > I’m fully aware that the company is to blame and not necessarily atlassian though The problem is that this anecdote is not even remotely surprising. I've used JIRA and/or Confluence at three employers and all three had wildly different, and awful, configurations. I have never worked with any technical folks who loved either, although I think on the whole Confluence is slightly better than JIRA. I thought the same thing for a long time - that Atlassian makes decent products that are often implemented poorly - but the problem is, at what point does it become Atlassian's fault for making products that seem so easy to implement so badly that developers will go out of their way to track work in Excel instead of JIRA?
  - user5994461 6y ago
    Counterpoint, worked at a large well known bank who had a massive JIRA setup, and it honestly wasn't bad. A couple of mandatory fields (department, team, application), that were manageable and that's about it. They even the JIRA during my tenure there. Made user sessions last for a while instead of being disconnected every 15 minutes.
- bberenberg 6y ago
  For what it's worth, you get the pros and cons pretty well. A large part of our business is based on taking these types of messy systems and move them forward to support the user needs. Feel free to email me if you think your company may be open to using outside help to clean things up.
Jare 6y ago
I was saying a couple weeks ago that one just ok system is better than 5 good ones because with 5 you never know which one of them has the thing you're looking for. Incidentally that conversation started with the suggestion to bring Jira into our already bloated set of services.
pc86 6y ago
Except for JIRA. I'd rather learn a completely new system every 90 days than use JIRA.
- jrott 6y ago
  I’m never sure if it’s actually core JIRA that is bad or if the problem is how customizable the thing is. It seems like every organization has added a bunch of custom fields and required bits that make it so annoying to use.
  - dnautics 6y ago
    yeah my feeling (this doesn't excuse atlassian of course) is that JIRA is fantastic if and only if you have a full time JIRA wrangling PM that is competent. Otherwise it's a dumpster fire.
  - manquer 6y ago
    Even a vanilla JIRA core on their cloud is slow as molasses, while there is slight improvement over the last year, they seem to be using more react on the frontend in each update. On a typical day moving tickets around , reviewing everyone's items and confluence with its WYSIWHG editor only approach is 20% of my day gone. Just making the UI non blocking for every single action would double my productivity. Their mobile apps are definitely better than web, so it is not like they cannot build decent interface and application, The web app just smells of legacy and debt to me. Even if its because of customizability they provide, it is really on them, to approve all sorts of plugins and for all straitjacketing they and/or AGILE ( as typically implemented) does to your development in the name of structure, restricting some of this customizability would not have hurt product more. Ultimately like any other SaaS business they serve the buyer and not the user. They are interested in what sells more, more often than not it does not intersect with what the users need. Customization sells, saying NO doesn't in enterprise. I guess we should be thankful they are not IBM or Oracle and build your kitchen sink and neighbours too I am tempted at least once every few months to just build a better interface and frontend which isnt' crap. Management is not going change from JIRA. Developers / users would happily pay out of pocket for a saner interface which helps simply manage their items without fuss, most people don't really care about the backend and the fancy reports, burndown charts for the most part, those who do can use the official app .
pvarangot 6y ago
I've never worked for/with a company that used Jira that didn't change the way you were supposed to use Jira every six to eight months or with any leadership changes at the project management or TPM level. Also I've never worked with two Jira setups that were the same. I'd rather use a tool that is flexible by default than use a rigid tool that you need to change every six months.

rad_gruchalski 6y ago

So, like jira every couple of months? Festures removed, ui changed...

LifeLiverTransp 6y ago
Braile is the new flat UI - you will love it once, you give this UX a try

dijit 6y ago

Man, I’d agree with you if my experiences with these tools wasn’t _so bad_. The current implementation of jira and confluence I’m using is worse than having _no_ ticket tracking and documentation system. Because if it didn’t exist there would be the impetus to implement something. But we just kinda barely limp by with what we have. It’s so barely functional that people actively avoid using it. I’m fully aware that the company is to blame and not necessarily atlassian though, as we have a number of plugins and random custom fields. One of the most dangerous things about jira is that it tries to be everything to everyone and people get carried away in the customisation believing they need it. It slows everything to a crawl and leaves you inundated with mandatory fields and a nightmare of matching stories with sprints and estimations in order to bring a bloody task in. Life was better with rt and mediawiki.

JoshuaDavid 6y ago
I think you're underestimating how bad the "something" people can come up with is. Think "weekly status reports to describe how you're doing on fixing a problem that was described through email, or an in-person meeting with someone, or a phone call, and never entered into a ticketing system at all". Also the mandatory fields are definitely a per-organization thing. At my org we have I think 3 mandatory fields, which are the project the ticket goes under, the title, and the description. In many cases, "migrating" from JIRA to JIRA but 90% of the features are disabled would probably be an improvement.
- stjohnswarts 6y ago
  If you don't have scripts that will fetch all your parameters and just have to fill in a couple of fields then you're doing it wrong.
  - JoshuaDavid 6y ago
    I do in fact have such scripts :). Also to automatically tag my git commits with the ticket, transition the jira issues appropriately when the relevant things happen with those branches or pull requests, etc. I don't actually interact with JIRA-the-application all that much these days, but in the rare cases when I do it's because I'm doing something non-trivial, and in those cases the UI seems relatively straightforward. ... I suppose that might be the main difference between people who hate JIRA and people who find it a little bit clunky but generally acceptable: people who mostly have the baseline stuff happen automatically are fine with it, and people who spend a lot of time interacting with the web frontend in repetitive ways hate it.
  - dijit 6y ago
    Uh... I’m having trouble envisioning this, do you have any examples? I ended up forcing my slack bot to issue POSTs to Jiras API out of frustration.
    - JoshuaDavid 6y ago
      Yes, exactly that. Basically wire up very simple commands with curl and jq that do the transitions you need, pulling data from other rest apis as necessary. The two workhorses of my integration are two methods named jira_get and jira_post. function jira_get { ENDPOINT="$1" PAYLOAD="$2" URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT" QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')" curl \ --silent \ --request "GET" \ --header "Content-Type: application/json" \ --user "$JIRA_USER:$JIRA_TOKEN" \ "$URL?$QUERY_STRING"; } function jira_post { ENDPOINT="$1" PAYLOAD="$2" URL="https://your-org.atlassian.net/rest/api/2/$ENDPOINT" QUERY_STRING="$(jq --null-input --raw-output --argjson x "$PAYLOAD" '$x|[to_entries[]|((.key|@uri)+"="+(.value|@uri))]|join("&")')" curl \ --silent \ --request "POST" \ --user "$JIRA_USER:$JIRA_TOKEN" \ --header "Content-Type: application/json" \ "$URL" \ --data "$PAYLOAD"; } Then if you want to get the available transitions, and required fields for those transitions, you can do ISSUE=PRJ-1234 ISSUE_JSON="$(jira_get "issue/$ISSUE/transitions" '{"expand":"transitions.fields"}' TRANSITION_NAMES="$(echo "$ISSUE_JSON" | jq '.transitions[].name')" and then given the transition in question, you can look at the fields required for the transition, and figure out where you get the data that goes in those fields normally. Any time the data that goes in those fields is obtained through a rote process, you automate that process, and then prompt for any fields you can't get in an automated fashion (e.g. "signed off by" you can fetch the reviewer names from the github api for the associated pull request). But yeah, a slack bot that issues requests to the JIRA api is a perfectly workable solution, and I think you'd be surprised at how much of a quality of life improvement you'll get by continuing to add capabilities to it that reflect your specific workflow.
pc86 6y ago
> I’m fully aware that the company is to blame and not necessarily atlassian though The problem is that this anecdote is not even remotely surprising. I've used JIRA and/or Confluence at three employers and all three had wildly different, and awful, configurations. I have never worked with any technical folks who loved either, although I think on the whole Confluence is slightly better than JIRA. I thought the same thing for a long time - that Atlassian makes decent products that are often implemented poorly - but the problem is, at what point does it become Atlassian's fault for making products that seem so easy to implement so badly that developers will go out of their way to track work in Excel instead of JIRA?
- user5994461 6y ago
  Counterpoint, worked at a large well known bank who had a massive JIRA setup, and it honestly wasn't bad. A couple of mandatory fields (department, team, application), that were manageable and that's about it. They even the JIRA during my tenure there. Made user sessions last for a while instead of being disconnected every 15 minutes.
bberenberg 6y ago
For what it's worth, you get the pros and cons pretty well. A large part of our business is based on taking these types of messy systems and move them forward to support the user needs. Feel free to email me if you think your company may be open to using outside help to clean things up.

Jare 6y ago

I was saying a couple weeks ago that one just ok system is better than 5 good ones because with 5 you never know which one of them has the thing you're looking for. Incidentally that conversation started with the suggestion to bring Jira into our already bloated set of services.

pc86 6y ago

Except for JIRA. I'd rather learn a completely new system every 90 days than use JIRA.

jrott 6y ago
I’m never sure if it’s actually core JIRA that is bad or if the problem is how customizable the thing is. It seems like every organization has added a bunch of custom fields and required bits that make it so annoying to use.
- dnautics 6y ago
  yeah my feeling (this doesn't excuse atlassian of course) is that JIRA is fantastic if and only if you have a full time JIRA wrangling PM that is competent. Otherwise it's a dumpster fire.
- manquer 6y ago
  Even a vanilla JIRA core on their cloud is slow as molasses, while there is slight improvement over the last year, they seem to be using more react on the frontend in each update. On a typical day moving tickets around , reviewing everyone's items and confluence with its WYSIWHG editor only approach is 20% of my day gone. Just making the UI non blocking for every single action would double my productivity. Their mobile apps are definitely better than web, so it is not like they cannot build decent interface and application, The web app just smells of legacy and debt to me. Even if its because of customizability they provide, it is really on them, to approve all sorts of plugins and for all straitjacketing they and/or AGILE ( as typically implemented) does to your development in the name of structure, restricting some of this customizability would not have hurt product more. Ultimately like any other SaaS business they serve the buyer and not the user. They are interested in what sells more, more often than not it does not intersect with what the users need. Customization sells, saying NO doesn't in enterprise. I guess we should be thankful they are not IBM or Oracle and build your kitchen sink and neighbours too I am tempted at least once every few months to just build a better interface and frontend which isnt' crap. Management is not going change from JIRA. Developers / users would happily pay out of pocket for a saner interface which helps simply manage their items without fuss, most people don't really care about the backend and the fancy reports, burndown charts for the most part, those who do can use the official app .

pvarangot 6y ago

I've never worked for/with a company that used Jira that didn't change the way you were supposed to use Jira every six to eight months or with any leadership changes at the project management or TPM level. Also I've never worked with two Jira setups that were the same. I'd rather use a tool that is flexible by default than use a rigid tool that you need to change every six months.