5 ms·

Ticket Monkey

56 points by zug_zug 5y ago

davidw 5y ago
Not sure if the tickets are really the problem. I've used them both in places that are soulless and places I've loved, because they're an effective tool for tracking a lot of things happening. Maybe it's just that smaller places more focused on getting stuff done in a hurry are more fun for some people.
- one_off_comment 5y ago
  I think you're on to something. I do find it interesting that I've noticed many product managers use ticket systems to track and reference work and changes, while programmers use version control systems to do something very similar. These two systems often link to each other via hyperlinks in ticket systems and ticket numbers in commit messages. The most coupled systems like git and Github Issues are still at arm's length to one another. Even Fossil (to the best of my knowledge) considers tickets and source commits/branches/etc to be separate entities. Maybe there's something worth looking into there that integrates the concepts more than just links and hooks. The bigger issue IMHO is that rush of endorphins when I complete a ticket. It's more fulfilling to me when I can quantify my productivity, and tickets allow me to do that. But that combines with the idea that your work = your worth, which is completely untrue. That's the core issue that I'm still trying to work on for myself.
  - oliv__ 5y ago
    > But that combines with the idea that your work = your worth, which is completely untrue I don't think it's either objectively true or false, but if you find it true for yourself, then it most definitely is true. There are few things more satisfying in life than interesting work done well
  - valyagolev 5y ago
    I often commit small org-mode style Todo files right in the repo (for personal projects), and it actually helps to see how the Todo list evolved with the project. It ends up not being a transient list of random stuff to do, but an evolving vision for the future. Maybe there's something to it...
yobert 5y ago
The strategy that has made me most happy is to divide my work time almost in half. Half is regulated, doing tickets, choosing the high priority long term work, documenting, and moving milestones. The other half, I always work on the most recently requested thing of me, or really whatever sounds fun, no matter how small or stupid it is, and I don't guilt myself over it. It has worked really well!
0xFACEFEED 5y ago
My issue with ticketing systems is similar to most issues I have with this industry: cognitive dissonance. On the one hand, companies ask me to put all this work into my tickets. Fill out this field, fill out that field, link to this thing, organize it this way... etc. On the other hand, the company puts NEAR ZERO real effort into making this experience easy and efficient. I've seen it happen most often with companies that flip-flop between defining themselves as a "start-up" but in the same breath talk about their worldwide enterprise presence. Of course they have 500+ employees. Sometimes thousands. They like to put on their startup hat when refusing to pay money for things and they like to put on their large scale enterprise hat when instituting ticket requirement policies.
- blowski 5y ago
  That’s not cognitive dissonance. It’s just the tendency of human ambition to outstrip action because of myriad reasons - lack of expertise normally being the root cause. It’s the same reason my shed is filled with expensive tools I’ve used once.
- meowface 5y ago
  Don't make me context switch between being an engineer/designer and being a bureaucrat. That's all I ask. (Okay, not all. It'd also be nice to have ticketing/project management software that isn't super ugly, clunky, and slow.)
- truffdog 5y ago
  And then you discover that no one ever reads any of the tickets.
  - nmstoker 5y ago
    It really does feel like reading comprehension limitations are a major barrier to people helping themselves. Even trivial amounts of text can put people off, even when the individuals are supposedly high calibre (ie university educated/heavily interviewed) The problem is this encourages brevity to the point of omission by the writers of tickets and then these various ticketing systems lose a big chunk of their value because no one has much of a clue what they're for afterwards!
cobertos 5y ago
There's definitely something to having face-to-face interactions. When I worked IT, I loved coming upon someone's problem, diagnosing and fixing it there, and making their day. I just am not able to do that behind a ticket system. Though sometimes I _like_ the predictability and transactionality of fixing a ticket too... Neither situation (informal issue passing via word of mouth, or a ticket system) even work close to 100%. A lot gets lost in translation. Maybe we just need less layers and more engaged engineers? People who care? Though hard to genuinely find.
- wildrhythms 5y ago
  I feel like I was able to solve problems with less friction when I was working in IT. I found a lot of personal and organizational value working one-on-one with the reporter of some issue: directly reaching out to them for more information, assuring them the issue is being investigated, serving as a liaison and sometimes hand-holder in its resolution, and leaving succinct notes and documentation for the next person who might come across whatever the problem was. Today, I don't get this same sense of 'ownership' over fixing a bug, or implementing some incremental sub-sub-feature in software engineering; at times I feel that I am not being trusted to interact with the reporter at all.
blowski 5y ago
There is a tendency for humans to want to systematise everything. We organise our bookshelves, write precise cooking recipes, track exercise routines. It brings comfort in chaos because it feels like there’s a plan. And the only thing less effective than an organisation with a plan is an organisation without a plan. The problem with plans is when we become bound to them, following them slavishly, failing to review them and update them based on new knowledge. That’s when tickets are awful. You’re doing a ticket because somebody you don’t know raised it for reasons you don’t know at some point in the past. Having “delivered” the ticket, you’ve no idea whether you’ve made any impact on anybody’s life, so everything feels like a waste of time. When tickets are done well, they are related closely to the impact they’re supposed to deliver, and represent a conversation about everything we’ve learned about that expected impact.
hdhjebebeb 5y ago
Tickets by themselves are a symptom of a good process and not the end goal. If you don't know where tickets come from, why they exist, or when to do them, then the whole process is nonsense. I've seen this repeatedly at places where they want developers to track what they're doing, but they don't have any product function to populate the backlog, groom it or prioritize tasks. It's basically anarchy but the devs just document what they felt like doing. Of course developers come to resent this system because nobody wants to read their diary - everyone else wants to know how close things are to being done. But because the whole project hasn't been scoped and broken down, it's impossible to get that knowledge from a snapshot of what people have been doing.
- whall6 5y ago
  From what I’ve seen that’s the only role that product plays to justify their existence
l0b0 5y ago
Ticketing (really, work tracking) needs to be adapted to each organisation. This is of course not a complete list, but some patterns I've seen: - In a three-developer startup a ticketing system might very well be just needless busywork. You probably have plenty of urgent things to disprove so that you can iterate as fast as possible. Put them on a whiteboard, and make sure everyone is on the same page about what you're building every day. - In an organisation where the tickets may live longer than someone's tenure a formal ticketing system may be necessary, if only to make sure long-term ideas are not lost or forgotten. - In an organisation with more than four developers working on the same thing long term you probably need tickets just - A lot of managers unfortunately don't realise how time-consuming and soul-crushingly boring it is to fill in every single field in an "advanced" ticketing system, like priority (just order things in the backlog!), severity (should be part of priority, not its own field), cost (ditto), deadline (ditto), sprint # (ditto dammit!), reported by (should be recorded automatically), and tags (who actually thinks those are accurate across the board and have the same meaning to everyone?). These orgs don't need an advanced ticketing system, but use them because they are more enterprise-y and that feels good to middle managers who care about visibility rather than productivity. - Huge orgs which have lots of geographically distributed developers working on the same thing definitely need an advanced ticketing system, if only so different people aren't doing the same work in parallel.
dsr_ 5y ago
A bug tracker is not the same as a work planner/tracker which is not the same as a ticketing system. A good ticketing system feeds into and is used by bug trackers and work planner/trackers. It instantaneously opens tickets from a variety of sources. Every ticket has a state, which starts out as New, and eventually winds up as Resolved, Requestor Did Not Reply, or Could Not Replicate. In between, there are various states of work that translate into Ready for Work or Waiting for Response, different queues for different groups in the company (and the ability to move a ticket between queues), automatic resetting of tickets to Ready for Work whenever a response comes in from the requestor... Then there are the necessary features: merge duplicates (and from then on, both ticket numbers are valid but indicate the same data); declare a parent (when the parent ticket reaches a final state, all children get the same final disposition); correct and document mistakes... You'll notice that all of these things reinforce how the business thinks the requestors should be treated: as customers, as teammates, as people who would like to report a problem, ask a question, place an order, document some work... but above all else, be able to ask what is going on with their area of concern and be able to get a reasonable reply as soon as one is available. If your ticketing system is not oriented to perform that basic task as a primary activity, it's terrible and I hope you can replace it with one that does without too much pain.
whall6 5y ago
I don’t know the answer, but I love the concept of people > process.

56 points by zug_zug 5y ago

Not sure if the tickets are really the problem. I've used them both in places that are soulless and places I've loved, because they're an effective tool for tracking a lot of things happening. Maybe it's just that smaller places more focused on getting stuff done in a hurry are more fun for some people.

one_off_comment 5y ago
I think you're on to something. I do find it interesting that I've noticed many product managers use ticket systems to track and reference work and changes, while programmers use version control systems to do something very similar. These two systems often link to each other via hyperlinks in ticket systems and ticket numbers in commit messages. The most coupled systems like git and Github Issues are still at arm's length to one another. Even Fossil (to the best of my knowledge) considers tickets and source commits/branches/etc to be separate entities. Maybe there's something worth looking into there that integrates the concepts more than just links and hooks. The bigger issue IMHO is that rush of endorphins when I complete a ticket. It's more fulfilling to me when I can quantify my productivity, and tickets allow me to do that. But that combines with the idea that your work = your worth, which is completely untrue. That's the core issue that I'm still trying to work on for myself.
- oliv__ 5y ago
  > But that combines with the idea that your work = your worth, which is completely untrue I don't think it's either objectively true or false, but if you find it true for yourself, then it most definitely is true. There are few things more satisfying in life than interesting work done well
- valyagolev 5y ago
  I often commit small org-mode style Todo files right in the repo (for personal projects), and it actually helps to see how the Todo list evolved with the project. It ends up not being a transient list of random stuff to do, but an evolving vision for the future. Maybe there's something to it...

yobert 5y ago

The strategy that has made me most happy is to divide my work time almost in half. Half is regulated, doing tickets, choosing the high priority long term work, documenting, and moving milestones. The other half, I always work on the most recently requested thing of me, or really whatever sounds fun, no matter how small or stupid it is, and I don't guilt myself over it. It has worked really well!

0xFACEFEED 5y ago

My issue with ticketing systems is similar to most issues I have with this industry: cognitive dissonance. On the one hand, companies ask me to put all this work into my tickets. Fill out this field, fill out that field, link to this thing, organize it this way... etc. On the other hand, the company puts NEAR ZERO real effort into making this experience easy and efficient. I've seen it happen most often with companies that flip-flop between defining themselves as a "start-up" but in the same breath talk about their worldwide enterprise presence. Of course they have 500+ employees. Sometimes thousands. They like to put on their startup hat when refusing to pay money for things and they like to put on their large scale enterprise hat when instituting ticket requirement policies.

blowski 5y ago
That’s not cognitive dissonance. It’s just the tendency of human ambition to outstrip action because of myriad reasons - lack of expertise normally being the root cause. It’s the same reason my shed is filled with expensive tools I’ve used once.
meowface 5y ago
Don't make me context switch between being an engineer/designer and being a bureaucrat. That's all I ask. (Okay, not all. It'd also be nice to have ticketing/project management software that isn't super ugly, clunky, and slow.)
truffdog 5y ago
And then you discover that no one ever reads any of the tickets.
- nmstoker 5y ago
  It really does feel like reading comprehension limitations are a major barrier to people helping themselves. Even trivial amounts of text can put people off, even when the individuals are supposedly high calibre (ie university educated/heavily interviewed) The problem is this encourages brevity to the point of omission by the writers of tickets and then these various ticketing systems lose a big chunk of their value because no one has much of a clue what they're for afterwards!

cobertos 5y ago

There's definitely something to having face-to-face interactions. When I worked IT, I loved coming upon someone's problem, diagnosing and fixing it there, and making their day. I just am not able to do that behind a ticket system. Though sometimes I _like_ the predictability and transactionality of fixing a ticket too... Neither situation (informal issue passing via word of mouth, or a ticket system) even work close to 100%. A lot gets lost in translation. Maybe we just need less layers and more engaged engineers? People who care? Though hard to genuinely find.

wildrhythms 5y ago
I feel like I was able to solve problems with less friction when I was working in IT. I found a lot of personal and organizational value working one-on-one with the reporter of some issue: directly reaching out to them for more information, assuring them the issue is being investigated, serving as a liaison and sometimes hand-holder in its resolution, and leaving succinct notes and documentation for the next person who might come across whatever the problem was. Today, I don't get this same sense of 'ownership' over fixing a bug, or implementing some incremental sub-sub-feature in software engineering; at times I feel that I am not being trusted to interact with the reporter at all.

blowski 5y ago

There is a tendency for humans to want to systematise everything. We organise our bookshelves, write precise cooking recipes, track exercise routines. It brings comfort in chaos because it feels like there’s a plan. And the only thing less effective than an organisation with a plan is an organisation without a plan. The problem with plans is when we become bound to them, following them slavishly, failing to review them and update them based on new knowledge. That’s when tickets are awful. You’re doing a ticket because somebody you don’t know raised it for reasons you don’t know at some point in the past. Having “delivered” the ticket, you’ve no idea whether you’ve made any impact on anybody’s life, so everything feels like a waste of time. When tickets are done well, they are related closely to the impact they’re supposed to deliver, and represent a conversation about everything we’ve learned about that expected impact.

hdhjebebeb 5y ago

Tickets by themselves are a symptom of a good process and not the end goal. If you don't know where tickets come from, why they exist, or when to do them, then the whole process is nonsense. I've seen this repeatedly at places where they want developers to track what they're doing, but they don't have any product function to populate the backlog, groom it or prioritize tasks. It's basically anarchy but the devs just document what they felt like doing. Of course developers come to resent this system because nobody wants to read their diary - everyone else wants to know how close things are to being done. But because the whole project hasn't been scoped and broken down, it's impossible to get that knowledge from a snapshot of what people have been doing.

whall6 5y ago
From what I’ve seen that’s the only role that product plays to justify their existence

l0b0 5y ago

Ticketing (really, work tracking) needs to be adapted to each organisation. This is of course not a complete list, but some patterns I've seen: - In a three-developer startup a ticketing system might very well be just needless busywork. You probably have plenty of urgent things to disprove so that you can iterate as fast as possible. Put them on a whiteboard, and make sure everyone is on the same page about what you're building every day. - In an organisation where the tickets may live longer than someone's tenure a formal ticketing system may be necessary, if only to make sure long-term ideas are not lost or forgotten. - In an organisation with more than four developers working on the same thing long term you probably need tickets just - A lot of managers unfortunately don't realise how time-consuming and soul-crushingly boring it is to fill in every single field in an "advanced" ticketing system, like priority (just order things in the backlog!), severity (should be part of priority, not its own field), cost (ditto), deadline (ditto), sprint # (ditto dammit!), reported by (should be recorded automatically), and tags (who actually thinks those are accurate across the board and have the same meaning to everyone?). These orgs don't need an advanced ticketing system, but use them because they are more enterprise-y and that feels good to middle managers who care about visibility rather than productivity. - Huge orgs which have lots of geographically distributed developers working on the same thing definitely need an advanced ticketing system, if only so different people aren't doing the same work in parallel.

dsr_ 5y ago

A bug tracker is not the same as a work planner/tracker which is not the same as a ticketing system. A good ticketing system feeds into and is used by bug trackers and work planner/trackers. It instantaneously opens tickets from a variety of sources. Every ticket has a state, which starts out as New, and eventually winds up as Resolved, Requestor Did Not Reply, or Could Not Replicate. In between, there are various states of work that translate into Ready for Work or Waiting for Response, different queues for different groups in the company (and the ability to move a ticket between queues), automatic resetting of tickets to Ready for Work whenever a response comes in from the requestor... Then there are the necessary features: merge duplicates (and from then on, both ticket numbers are valid but indicate the same data); declare a parent (when the parent ticket reaches a final state, all children get the same final disposition); correct and document mistakes... You'll notice that all of these things reinforce how the business thinks the requestors should be treated: as customers, as teammates, as people who would like to report a problem, ask a question, place an order, document some work... but above all else, be able to ask what is going on with their area of concern and be able to get a reasonable reply as soon as one is available. If your ticketing system is not oriented to perform that basic task as a primary activity, it's terrible and I hope you can replace it with one that does without too much pain.

whall6 5y ago

I don’t know the answer, but I love the concept of people > process.