2022-03-12

Rant: Ticket System

~starbreaker commented:

Nothing wrong with the ticket system that can't be fixed with the judicious application of high explosives.

Yes well. While I'm not qualified to handle explosives, a brave

rm -fr /path/to/jira/database

would probably do.

This is going to be a nasty rant. If you are not in the mood of rants, leave now. If you are not willing to accept, that none of this computy stuff is neither intuitive nor self-explaining, then think twice about leaving now. I don't care if anyone is reading this, let alone if anyone agrees. You have been warned.

Context

At dayjob we use Atlassian Jira (after having tried redmine and trac before). Once in a while I am forced to deal with the mess called tickets, excuse me "Tasks", or worse the backlog of said items. To exactly noones surprise these days make me angry fast[a].

Paragraph 1: The Ticket is only the Ticket and not Real Life!

Ok, I admit, I'm a little opinionated here: as a person with a doctorate degree in physics, I have spent a bit of time thinking about the relevance of a concept (like electrons, say) to real life (do these electrons really exist?). To make it short, a concept is a concept. And real life doesn't care a whee bit about my or our or someone elses concepts. Thus I conclude: electrons are a concept, they exist only in our mind. The concept is a somewhat successful attempt to summarize a set of observations. Electrons do not exist, they only exist in our minds.

That being said: The tickets in any old ticket system are tickets. Their content may summarize certain aspects of (technical im my case) real life. Their success wildly varies, but it's never better than say 20% or so. Real life is much too complex to be condensed into a bloody Jira Task.

Paragraph 2: I don't need no bloody Tickets

Yes. I don't. I personally do not need these tickets. Why? Easy. I have emacs and org-mode and I keep a list of TODOs in a file called 1_todo.org. This file is structured, TODOs go into categories, e.g. into a specific project, which corresponds to a given target hardware. The project may be renamed any old time, the target hardware stays. Its hardware, after all. We might not have it available any more in production, however, it continues to exists at customers site[b].

So I have a "shadow-Jira" in emacs. The whole world of emacs possibilities at my finger tips. Rarely a need to grab the mouse. Large enough monospaced font everywhere. A bit of coloring (think font-lock) goes a long way[c]. Free form text, any language I prefer, rough, with edges, including a set of obscure jokes, inexplicable references, you name it. And the unwritten assumption, that /any/ of the written words may be wrong, always or since some time. This is my documentation for my brain. And as I have written elsewhere, my brain dump journal at day job has accumulated >250000 lines (>10 MB) in 5 years[d].

Corollary: Who needs them Tickets, anyway?

This is the interesting point. If I don't need them Tasks, who does? Well, those poor souls called project managers, they need them. Their perspective on real life is totally different from mine. For them the mile-high pile of funny and not so funny details about my portion of real life is ... invisible. They know to some extent, that this pile exists, but not more. These poor souls are unable to survive dayjob without the perspective that these tickets hold. Fair enough.

From my egoistical point of view Tickets are pretty much a SEP (somebody elses problem, thanks Douglas). Before you ask: I'm not against documentation, I do use Atlassian Confluence for that. The main work is to create a structure, that is navigateble, including links to other documentation, external references, code, you name it. And no, the search interface doesn't cut it. Unfortunately some external components cannot be referenced in usable links.

Paragraph 3: GUI Interfaces are just that

This has nothing to do with the importance of tickets or lack thereof. This section is pretty much exclusively about my inability to deal with the Jira Webinterface as configured by my lovely colleages to the best of their knowledge.

Fonts

I grew up on computer terminals with 80x24 monospace layout. Green glyphs on black background. Maroon glyphs later. A separate view for graphics, I could watch the pixels of my formatted LaTeX-document arrive in small groups --- they were carried over the cable by the Turing omnibus, as the joke of those days goes.

Things have become incredibly fast since then. The 80x24 limit fell, monospace font was not a boundary condition any more. Near this point in time in this universe some poor soul had to define the "default font" for things computy. And they settled on Arial: proportional font sans serifs. That programmers cannot distinguish zero an Oh '0O' or Ih, ell, one 'Il1', in Arial, to hell. Something is up for sale always.

Things are still manageable for me, if content and presentation are separate things. I can select monospace font and be done with it. But alas, in email I have to select monospace font every time I start typing a new message. In Confluence and Jira, I haven't even tried. Because my presentation is then forced to everyone else. The separation has been dumped long ago. In Confluence I cannot edit text in raw form any more, another workaround gone.

Long story short: I cannot read Arial well, even if I increase the font size quite a bit.

GUI Elements

Context: I can see well, I wear glasses, I do not suffer from any color blindness. More Context: [e]

When interactive elements on web pages came into use, they looked like buttons. They visually snapped, when pressed. That was taken straight from the desktop GUIs of the time, like CDE (common desktop environment). These buttons looked like buttons. I could find them. Plus they were always there. Nowadays a button is flat. I's middle gray on a light gray background. It doesn't visually snap. Most of the time it's not labeled with text but with mostly inexplicable symbols.

Worse: buttons which hide. They become visible only after I hover the mouse pointer over some element, or worse, if I actively select some other element. This often presents an insurmountable barrier to me.

Even much more worse: I have found that the "workflow" button in a Jira ticket does not show all possible states. I can identify this as a button, because it has some "v" icon attached, which makes me suspect a selection list to open. Strangely two of the possible states are missing. It took someone else to point out that the two missing states (Draft, Ready for Implementation) were separate buttons to the left of the workflow button. GUI Designer: 1, me: 0. I am unable to see any structural consistency here.

There's more: Creating a new Ticket. I press the blue "Create" button in a ticket view. A new thing opens. Well, not really, the current ticket is shaded out with a dark grey overlay, and a dialog box opens.

• this dialog box covers about 1/16 of the available space for no apparent reason.
• this dialog box is not resizable.
• the first button (select project) is only half as wide as the dialog box, and it is clearly not wide enough to display the whole text of the project names/descriptions. If I need to read the tail end, I need to select the entry, then move the cursor to the back of said text. All this while about 90% of the screen estate remains unused.
• the selected entry disappears from the selection list for no apparent reason.
• the dialog box really is twice the size that is shown. It helpfully features a scroll bar at the right side. That again is flat and gray on some other gray. I failed to see it on the first attempt. I failed to operate it on the second. And the important stuff is down there on the second half. All this while about 90% of the screen estate remains unused.
• I have learned that small red asterisks denote mandatory fields. Can we please make them gray and the size of one pixel? So I don't see them? There is space for making this even worse.
• So, after all this I press "create". All well? No. The popup dissapears, an small popup with small fonts occurs somewhere to tell me about the new ticket number. I failed to see this. Because that second popup disappears after a few seconds.

My expectation at this point is, that the newly created ticket opens in the place of the one, where I was, when I pressed "Create". But no. I have to somehow search for this ticket now. All this, plus I don't need them tickets anyway. Sigh.

Boards

Is he done yet? No. When I log in to Jira, I am presented with a thing called "dashboard", whatever this is. Someone explained to me, that I can place fancy things here, like the list of my assigned tickets, or the activity trail, or whatever. So I made an attempt to place the "tickets assigned to me" list there. In vanilla configuration this list is completely useless.

• It has too many items. Oh well, my fault right? If I don't close them tickets or assign them to SEP, the list will just grow. Challenge accepted.
• I work for serveral projects simultaneously. Such is my role as a systems integrator. And I need them bloody tickets grouped by project. I'm quite sure, this can be done, but I need to spend an unknown amount of time to get there. And afterwards I might not like it :-(
• If I assign a ticket to someone else, because I need input, the ticket is gone. It might never return. Problem solved? Well, maybe not.
• If I don't assign a ticket so someone else, but instead rely on email, phone or some other means, then it remains on me to update the ticket. I have become increasingly allergic to doing other peoples job --- most notably to fill in the document, which collects the requirements.

I have asked for a thing like a canvas, where I can place links to individual tickets and some lines/arrows and some text. Like I would do on my white board. Not available. I have no good idea, how to organize these tickets in such a way, that my brain can navigate them in a meaningful way.

Paragraph 4: Life of a Ticket

Ticket Content

I have learned the hard way, that my view of what needs to be done to achieve some deliverable is utterly useless, when it comes to transfering this view into tickets. I'm at a complete loss, how to organize them. I will not organize tickets outside of my narrow scope. I have learned that ticket of the sort "make it work" are useless. They are too large. They never get closed. I accept, that I need to help with the creation of tickets to organize some project or product, but I'm unable to see, how to do this in such a way, that it is helpful for others and not driving me mad.

So I will try this:

• I will reject tickets without detailed description of the deliverable, and without a clear way to determine whether it is completed or not.
• I will reassign tickets which are waiting for input from someone else to this person immediately. Not in my backlog, problem solved. If it doesn't come back, not my problem.
• I will reject tickets, which are too big. If I have a nice day, I'll add a suggestion, which portion should show up in a ticket.

Workflow

No, I'm not done yet. I have one more galling insult in this whole mess to report. A ticket is created in state "Draft". Fair enough. It is only visible in my backlog. It is then promoted to "Ready for Implementation", at which point it shows up in the left column of my kanban board. Fine. "In Implementation" moves it to the middle column. However, that should set all other tickets in this column to "blocked", I think. When I'm done I promote the ticket to "Ready for Verifcation".

Sounds good? It isn't. Noone is ever doing verifcation of my stuff. Since the beginning of this year, I have a new colleage, who is able to review my stuff. And that is good. He's smart and asks clever questions. But verification? That would need some well documented requirements, wouldn't it? Where are they? Ok, as a workaround I collect my own, however, those are on implementation level and not as seen from a production/customer/service point of view. So I can skip this step and just select "Done" without any loss of generality. And I know, this is wrong. A developer should be unable to release his deliverable directly into production. But well. Maybe in another universe.

tl;dr Conclusion

• Jira Tickets are tickets, and not Real Live(tm)
• I personally to not need Jira Tickets
• The GUI side of affairs is so different from my pattern recognition and habits that it imposes a significant impedance mismatch to my interaction. I could think of less polite descriptions easily.
• I don't know, how to create good tickets. And I don't see this as being my job anyway.
• Working for several projects simultaneously doesn't make it any more simple or easy.
• I'm not going to do other peoples' work.
• I'm not the project manager, and I never will be. I'm not going to run after other peoples' work or lack thereof.
• I'm unwilling to accept the lack of verification taking place.

I would actually be interested to hear, whether I'm alone with this (suspect no), and whatever comments you can make. Thanks.

~ew

---

• [a] From Zero to Bitch in Point Three Seconds!
• [b] Aside: I have seen a developer being forced to throw his large collection of old hardware into the bin. Top manager watching. Only to be forced in the following months to refill his stock from elsewhere, because he bloody needed the old crap to make sure, that new software would still run there. Unbelievable.