Tickets, Reluctantly

Ah tickets, they go by many names. Work items, stories, tasks, spikes, features, backlog item, etcetera. We love them so.

They’re all more or less the same thing, a little digital post it note where you can write down the what and why of something that needs doing. They’re also often harmful to the successful delivery of valuable software.

Why is this? It’s the same old story. Doing anything, absolutely anything, has cost. Clumsy ticketing systems, even in relatively small orgs, manifest this cost in some particularly gnarly ways. I’m gonna talk about it.

I contend that when you go to log a ticket in whatever change management system you use, you are expressing one of two things:

Neither of these things are unreasonable, although I do think they are unfortunate. Would it not be better to be able to address your own problems, and it wouldn’t it be better to be able to deal with any issues you see immediately, rather than needing to delay? Nonetheless, you can see what this sort of ticketing buys you organizationally, specialization and the avoidance of context switching, both of which can be helpful.

Even so, there are additional trade-offs that come just from the act of logging tickets. This point of this article is to contend that these trade-offs, more often than people acknowledge, outweigh the benefits of logging tickets at all, and in many instances it would be better to record nothing.

Before I break down the details, I need to address a philosophical point. I suspect some will balk at this idea. Record nothing at all?! That’s absurd! In my experience, this attitude comes from an instinct that it is inherently virtuous to have a single store of all context around a project. It is simply good to write things down. I contend that this is an example of religious thinking. Why is it good to write things down, what specific benefits does it have to the successful delivery of a project? What specific downsides does it have? We are engineers, we do not get to abdicate our duty and rely on heuristics unconnected to final value.

That isn’t to say that there is no organization where writing down most things is the correct trade-off to make, but in my experience most of the foundational thinking in this area is unconsciously sourced from various scrum industrial complex assumptions, and never examined in an organizations specific context. There is no one correct way to develop software, we must have realized that by now.

That being said, here are the things I most often notice as issues with logging tickets.

Expressing the wrong thing

Are you the right person to write this ticket? Do you know what the fuck you’re talking about, and can you express it well enough that it won’t cause an overburden of confusion?

People tend not to get trained how to write tickets, and software is complicated and often non-deterministic. People do misinterpret, and they do make assumptions on what the “fix” to their problem should be. This creates overhead on the part of the person who eventually needs to deal with this ticket. They have to do work to decode and understand what is actually going on, which isn’t free as they’ll have to agitate the organization in order to do this. In poorer technical cultures, they will simply do what the ticket tells them, delivering net negative value as they build the wrong thing. In these cases, it would be better if the ticket had never existed at all.

Temporal Rot

Tickets are static artifacts, they don’t update as time passes and underlying technical and social context changes. This is obviously a downside of the medium, and it’s a big one.

Some organizations habitually delete tickets that are older than 12 months or so. I think this is almost always a good idea. Temporal rot causes all the same negative outcomes of the ticket being malformed in the first place, but it can happen to any ticket, no matter how well considered it initially was.

I have seen PMs place tickets over 3 years old into backlogs without understanding what is written in them beyond thinking that the title relates to what the team is trying to do. It sounds trivial, but this can cause such utter chaos, especially on teams where the engineers are not as confident or outspoken as they should be. Please stop.

Illusion of Understanding

Fans of Seeing like a State may retort that yes, these are problems, but we do them for legibility. They may cause the organization to be inefficient, or even clumsy, but it allows the organization to make effective decisions which is, in the long run, much more important.

My friends, has that ever been your lived experience?

Whilst I don’t deny this sort of legibility is possible, you don’t get that for free. An under-considered (ie, most of them) implementation of ticketing will lead you to having less legibility, not more, as members of your organization merrily delude themselves into thinking they know what the fuck is going on.

I don’t think I need to harp on this one too hard. I’m sure you’ve had non-technical PM’s, leads, or even engineers, who seem to be doing nothing but playing ticket tetris. You’ve had people who seem exclusively concerned with progressing the ticket and not at all concerned with the value it would represent if manifested. Unfortunately, we as an industry have been hoodwinked into believing that this sort of work is legitimate and valuable enough to justify entire positions.

This is especially frustrating as I am certain the people doing this sort of “work” feel frustrated and impotent too. There is a need for a “true PM” role, I’ve worked with a rare few who were overwhelmingly valuable. They did this by caring about tickets only as much as it helped them, they were much more concerned, and much more fluent in, the tangibilities of the product itself. Let us free these people from jira-jail and allow them to be valuable once more.

Experiencing all this, one might start to think that delivering value, or even making profit, isn’t really the point here. One might start to think that control, or even the illusion of control, is the output we’re trying to produce from these machines. Now of course I would never say that the current economy is exclusively setup to trick those at the top of our socio-economic hierarchy into believing they have self-actualized, like the no-clothed kings of old. Me? Never.

Putting that useless (but fun!) rant aside, we must all realize that you cannot contribute to successful software delivery if all you have to ground your interpretation of any given ticket is the information contained in the ticket alone. The map is not the terrain, and ticketing systems, treated naively, are maps with more noise than signal. If you find yourself logging a ticket, ask yourself if this ticket is likely to be materially useful. If not, just don’t log it, your colleagues won’t thank you, but I will.