Perspectives on Issue Tracking

Bugs, issues, tickets: They go by many names but serve the same purpose—tracking a task that needs to get done. It’s the lifeblood of project management in the tech industry, where nothing gets done that isn’t tracked somehow. And, like most invented concepts, it’s simply a formalization of our innate ways of thinking about tasks.

Humans have probably been trying to quantify work ever since we started hunting together. But modern-day project management traces its lineage back to 1911 when Frederick Taylor published The Principles of Scientific Management, which aimed at systemizing the job of an individual worker to maximize output for the enterprise.

Taylor targeted workers in the American steel industry, grounded in the belief that they weren’t working at full capacity. He promoted the use of time studies on different ways of performing atomic units of work, like striking hot iron. If there is a particular way of striking that’s quicker than the others, every worker will be instructed to do it that way. He claimed that this improved the overall productivity of the firm, leading to an increase in the workers' wages.

In a similar vein, today’s issue trackers attempt to turn the organic process of creating software into a structured, manageable science by atomizing work into trackable issues. There is a plethora of tools to help you track these issues: JIRA, Github Issues, Bugzilla, and Asana, to name a few. You can even use plain old sticky notes if you like.

In the quest to carve out a market share, there’s been an explosion of diversity in these tools. The underlying structures, however, remain fundamentally the same.

Fundamentals of an Issue

To understand what characterizes this issue, let’s look at how issue trackers model them.

The process governing this lifecycle is largely determined by the software development methodology that a team follows. If you’re reading this in 2019, chances are that your team follows some variation of the Agile method. Browsing through top LinkedIn titles should show you that it’s a pretty good time to get into the business of certifying scrum masters.

Although trackers base their data model on this simple construct, they vary how it’s presented to the user based on the intent. Driven by growing user needs and basic market forces, issue trackers have evolved into complex tools that often serve multiple purposes.

Issues as a Planning Tool

From building extravagant monuments to daily commuting, planning is ubiquitous in human activity. When set on achieving a goal, we instinctively anticipate the future and prepare a plan of action. Along these lines, issues that track expected work can be viewed as tools that help map out the territory of the problem space before breaking ground on execution.

The choice of methodology largely dictates the approach to planning. Since Agile encourages an iterative approach to software development, issues are created more on demand and have relatively short lifespans. Teams are advised to stay flexible and respond quickly to feedback. Since plans are liable to change, it’s less useful to flesh out the details of a task further out.

Issues often have a dedicated field to store an estimate of task effort, like story points. The value in this field represents the approximate period of uninterrupted work needed by an ideal engineer to complete the task. The issues and estimates provide an overview that assists in resource allocation and tracking project progress. There’s nothing like a burndown chart to spice up a bland executive status report.

However, exact estimation is a tricky exercise. Behavioral science has long known about the Planning Fallacy, that we tend to greatly underestimate our task completion times. Perhaps unsurprisingly, social scientists have found an actor-observer difference in our predictions. We tend to be much more conservative when estimating others' completion times. It may be a good idea to ask a teammate to keep you honest the next time you’re making estimates.

It’s also easy to fall into the trap of obsessing over the accuracy of estimates while missing the bigger picture on the purpose they ultimately serve.

Issues as Task Lists

When it comes time to execute, it’s convenient to have neat lists of tasks for people to start work on. Assigning an issue to someone holds them accountable for progress. However, a person will usually have multiple issues assigned to them, and picking the right one to work on is a dilemma.

Not all work is created equal, and some tasks are bound to be more critical than others. To indicate this, trackers allow you to specify priorities on issues and display issues in sorted order. Most people in the tech industry will be familiar with the process of triaging: ranking bugs by importance. It borrowed heavily from the process of medical triage, which can be traced back to Napoleon’s failed campaign in Egypt and Syria.

Before this, the seniority of an officer usually decided how they were treated by medical staff. Faced with a dire strain on resources, “Napoleonic triage” prioritized the treatment of soldiers who could be sent back to fight in the battlefield. This later evolved into a system that allocated medical resources based on the severity of the condition as opposed to the rank of the patient.

While the consequences of bug triage aren’t as severe, the same principles apply. Issues should be prioritized by objective severity metrics as opposed to subjective value judgments.

Issues as a Medium of Communication

Despite the prevalent meme that all tech people are misanthropes, day to day software engineering is very social. Sharing information is crucial to performing our jobs in the hyper-specialized world that we inhabit. Over time there has been a steady increase in the number of communication tools available to the average employee.

When it comes to sharing findings or progress updates on a task, picking the right channel and determining the appropriate target audience can be a challenge. There’s also the problem of fragmentation, which makes it harder to aggregate discussions about a particular task. To help solve this, trackers support commenting on an issue.

On the surface, it seems like this just exacerbates the problem by adding to the list of possible choices, but there’s something deeper at play. Game theorists study coordination games in which players maximize their payoff by picking the same action. They have observed that players with no prior history tend to cluster their choices around Schelling points, which are semantically salient options. An issue provides a focal point to which uncoordinated actors can anchor their discussion about an ongoing task.

Issues as a Knowledge Repository

Having a centralized coordination place for things related to a task also simplifies the process of searching for information. Other tools, like version control systems, are usually integrated with issue trackers and link their transactional objects, like code changes, to issues. The consolidated log of comments and other items related to an issue forms an integral part of an organization’s memory.

A chronology of actions on an issue also provides the basis for a coherent narrative, weaving a story around a task. These stories allow us to play through events and contextualize decisions. This is particularly useful during post mortems. During such investigations, issue histories are invaluable in tracking down culprits and figuring out exactly why things went wrong.

Issues as Outstanding Debt

When an issue is created, there is an implicit expectation that the underlying task will be completed in the future. So another way to think of issues is as a promise to deliver something at some point. This sounds very similar to a concept anybody with a credit card must be familiar with—debt.

Like interest on the principal amount, the longer an issue stays open, the more the costs accumulate. For example, if the issue tracks a code health improvement, developers working with the codebase pay the running cost of having to deal with the bad code while making changes.

One must be careful about stretching this analogy too far though. Someone once told me about a team that had too many open bugs and decided to declare *bug bankruptcy—*closing all unassigned bugs. It initially seemed like a great idea, but within a few weeks, they had almost the same number of bugs as before. Simply addressing the symptoms doesn’t cure the actual disease!

The problem was never with the bugs themselves; they simply represented the state of the software when contrasted with the ideal. Closing the bugs without revising the ideal state didn’t change the amount of work needed; it just temporarily erased the effort people put into mapping out the steps to the ideal.

All Things in Moderation

Issue tracking is a handy tool but also tends to be overused. We must keep in mind that most attempts to direct human effort endorse a slightly adversarial view of human nature. There’s a latent assumption that people won’t do the right thing until they are explicitly instructed to, which isn’t necessarily true.

Individuals and interactions over processes and tools.  — Agile Manifesto

Scientific management also carries a strong undercurrent of high modernist thinking, the belief that all natural processes can be optimized by technology. As James Scott lays out in his book Seeing Like a State, the subtleties of our organic ways of doing things are not always apparent to the planner focused on optimizing.

It’s especially important to remember this when working in an industry that pays the bills by selling technology to solve problems. Overly dictating how a worker should spend their time deprives them of autonomy and amplifies feelings of monotony. Sometimes, trusting people to do their jobs without excessive supervision isn’t a terrible idea.