The evolution of issue tracking

In software development, issue tracking, sometimes known as bug tracking, is any system used for annotating, organizing, and managing issues until they are resolved. 

But to really understand issue tracking, we must also define what we mean by an “issue” in this context. It originally meant a bug report or feature request. An issue had properties like: description, status, assignee, and creation date. Over time, the meaning of issue evolved into a more abstract data structure which additionally may represent a software test, employee activity, employee task, group of other issues, etc. And issue properties have expanded as well.

Sometimes known as bug tracking, “issue tracking can employ a database for annotating, organizing, and managing issues. So generally, an issue is a record in an issue tracking database.

This is the history of my experience with issue tracking as a software developer. This is not a product review, comparison, or broad historical survey, but rather, my experience. 

Simple verbal issue tracking

When I was a university teaching assistant, we had issues but no formal issue tracking. My software development organization consisted of a developer (me), a product manager (graduate teaching assistant), and a business owner (professor). Issues were conveyed verbally, and they were addressed sequentially and quickly. Issues described verbally could be ambiguous or misunderstood, which occasionally led to wasted effort.

A general-purpose database for issue tracking

In my second programming job, we used a commercial database which we configured for issue tracking. The database was not accessible outside the office. Issues could be searched, viewed, and created by any employee, provided they had the commercial database client application on their computer. By using issue tracking, we could describe issues in arbitrary detail, assign them to specific developers, and accumulate information over time about bugs that were difficult to reproduce. Despite its limitations, this system did one thing and did it simply and effectively.

Ad hoc issue tracking systems with some integrated project management 

My next gig, which lasted 16 years, was for a large technology company, and each development team handled its own issue tracking. For small teams, this was generally informal. Over time, some larger teams started using web-based software that was not only designed for issue tracking but incorporated rudimentary project management features. Product managers and project managers got involved directly, entering intent, setting and re-setting priorities, and looking at who was working on what and how long it was taking. With greater integration across domains came greater issue tracking complexity.

Standardized, integrated software for issue tracking and project management 

As of this writing, I work for Capital One, where we have standardized on Atlassian’s Jira software. Jira handles both “issue tracking” and project management. In its project management capacity we use Jira for things like planning, tracking test results & releases, reporting and analyses. The additional complexity that comes with integrating issue tracking with project management remains, but project management features have been built out considerably.

• Integration of issue tracking with project management 
  This allows for powerful tracking and visualizations. It also allows ownership of issues to shift from developers to product managers, which works well in an organization that has specialized roles. (Note: There can also be a downside to this integration though, which I’ll share in the next section.) 
• The ability to group related issues 
  This can help with organizing issues, working with issues in batches, and creating visualizations.
• Linking issues with source code changes 
  This provides a trail of breadcrumbs to help understand why a code change was made, and it provides evidence that an issue has been addressed.
• Attaching documents (e.g., screenshots, movies, log files) to an issue 
  This can serve many purposes, including showing the outcome of a bug or demonstrating how to reproduce a bug.
• Not having to deploy or maintain a database for issue tracking
  This isn’t necessary anymore, given the off-the-shelf solutions. This can save time and money.

• Changing the metaphor 
  Integration with project management can change the meaning of an issue from “something that needs to be done to a product” to “something that needs to be done by an employee.” In other words, sometimes employees wind up being tracked rather than the products they’re working on. 
  Furthermore, because an issue may abstractly represent a software test, employee activity, employee task, group of other issues, etc., it muddies the metaphor and adds cognitive complexity. Additionally, in classic issue tracking, the status property had a short, clear set of possible values, such as: “New”, “In Progress”, “Done”, and “Canceled”. 
  With project management, possible “status” values may expand to the point that the software offers a flowchart to describe how an issue may transition logically from one status to another, and organizations may even lock employees out of setting some statuses as a way to enforce process.
• Grouping issues
  When issue tracking is combined with any other type of database, there may be new ways to group issues other than by feature (e.g., by due date), which are useful. But alternative grouping can be limiting if it’s a replacement—developers may still prefer to group by feature.
• Proliferation of features
  Per The Innovator’s Dilemma, popular issue tracking tools continue adding new features of lesser value for the average employee, which can make it more cumbersome to use core features. It can be tempting to add custom properties that serve specific needs in searching, sorting, reporting and analyzing issues. 
  But they often don’t get used consistently and ultimately become a source of noise for the average employee. Additionally, as reporting and analysis requirements change, it may be necessary to add still more properties, while other properties are abandoned. This can be partly mitigated by the use of labels or tags, though consistent use remains a problem.
• Access control granularity
  We certainly want to protect the sensitive data in our databases. But offering access control to individual database features may be overkill and is certainly subject to misconfiguration. I, for one, have had the experience of not being able to do something innocuous like save an issue filter because the feature inexplicably was locked down.
• Non-native user interface
  At one time we used native apps to access the database, with good usability and responsiveness. Now we use web apps to access the database, which has its tradeoffs.

• Support for domain-specific database views
  Employees would be able to focus on the needs that are specific to their roles. Developers could view issues in a classic issue tracking interface, while project managers could view issues in terms of timelines.
• Support for multiple groupings of issues
  For example by feature or by due date, would allow an employee to focus on an issue grouping that makes the most sense for their use case. For any role, the ability to visualize a grouping by feature could help avoid accidentally creating duplicate issues.
• By applying principles of good user interface design
  Such as progressive disclosure, an employee can use features relating to how they typically use the database without being overwhelmed by unrelated features and without being blocked from using other features when necessary.

The integration of issue tracking with project management has been a big help to project management, but it has made issue tracking worse in some ways. There may be a path forward that greatly improves issue tracking without giving up the benefits of the integration.

Employees with different roles have different methodologies, priorities, and vocabulary. A solution intended to support multiple roles should do so without reducing usability, when possible.