I built 6 issue trackers in my career. Here’s why they all sucked
Yes. I wrote 6 issue trackers, over a 12 year period. One is used as the main issue tracker for a company which provides enterprise software for e-banking. It was translated into three languages the last time I checked, because the company is so big it services banks from several countries. The company is using it daily now for almost a decade. They live on it.
But it sucks. It sucks hard.
There are many reasons why the software itself doesn’t suck. It was build with specific functionality in mind, providing everything the company needs to track and resolve issues in their B2B sector. For them it’s the best thing since sliced bread. It does exactly what they need, and not much else.
Suck 1: specificity
Let some other company pick up the same software. It’s big, requires a lot of data input for submitting an issue. Some things are not important in other sectors, while other things are — people want to track different things depending on what their process is, what key information is important to track down and resolve issues.
Some of this data needs to be structured. If it’s not structured, it means that there is this big “content” field, where people type in whatever they want. They describe the issue sometimes with terms which are unique to their domain, and might mean different things to other people. Especially in content management, there seem to be many ways to describe the same thing — the “Hero unit”, the “Slider”, and “Landing banner” might all mean the same thing, same goes for “Popup” or “Modal window”, even if they are sometimes far from the same thing. Lack of specificity takes time from the worker, and overabundance of specificity takes time from the submitter.
The WORST thing that happens is when the worker goes back to the client to request more information. This ping-pong is deadly for resolving issues as in some cases it takes days or even weeks to get a reply.
Suck 2: features
Sure, you’d think that features are very useful thing. You’d be wrong. They suck. You can add features which on paper look very helpful, and useful, and great. You can add them and people will be happy, but over time, all the features will do one or two things that severely suck and decrease the love to issue tracking.
Example 1: prioritizing issues by due date/other criteria
One of the issue trackers which I made had a defined color scheme. The color scheme was kinda on the scale from green to red, giving a visual indicator at what state some task was. This sucks.
It doesn’t work for one very simple case — dependent tasks. You can have one very long very hard task which needs to be finished, before you can finish another in just about an hour or two. Both tasks have the same due date, but one has progress at 0%, so there’s the indicator which shouldn’t even fire before the primary task is complete. And then you extend the logic to handle this edge case, and extend it even more for others.
You end up with a feature of pure suck, which nobody understands anymore. Nobody knows how it works, why it works that way, is it working correctly or not, and that sucks very much.
Example 2: how to manage tasks
For some people, an issue can be as simple as a normal check box. Is it done? Check it and forget it. People do it from mail clients. Other people want to have a whole checklist for one issue. Awesome, you even get a progress indicator out of it. It’s still kinda fine. Other people link issues between each other as prerequisites or composite issues. F-f-fine. And there’s that guy who comes in and want’s the whole thing on a Kanban board. And another who shits on the whole thing and wants some kind of Agile scoring system for each issue. F-f-fuck my life.
Realize that most likely, not everyone will be happy.
How people order information is not standard in any way shape or form. Some people divide and conquer, and other people delegate. I mean it in the best possible way — both of these approaches are perfectly fine, for two different types of companies and management scenarios. Even with the help desk software working fine for one client, you just know that it’s not suitable for use as an issue tracker in an Agile development team.
Just by definition anything you make here sucks for most people.
Example 3: time tracking
So many times we tried to bundle a time tracker into the issues. Oh god it was a failure every time. With some discipline you use it, but eventually you just fall back on what’s easier. It’s an Excel sheet, or a Google Docs sheet. Mostly it’s easier because there is not one actionable thing you can do with hours. For whatever client report you need, you just copy paste the relevant sheet out of the Excel file and you’re done.
The main reason for this, is that each individual is split between three different times at work. It’s the time you are actually productive (#1), the time it takes you to finish a task (#2) and all the time you spend at work (#3). The division of time is always from #1 towards #3 (least to most time spent). Time tracking is flawed because different people expect different things from this. Some management type is expecting that time is billable (closer to #1), and if you’re spending 10 hours at work in a day, that you’re under-performing with only 6–7 logged hours on issues. On the other hand — that’s exactly how lawyers work.
For a smart attorney with a solid work ethic, it typically takes about 10 hours in the office to accrue 7 billable hours; tracked most often in 6 minute or 1/10th of an hour segments.
If you’re like me, you have off days. Off in the sense that you can’t focus and you can, instead of work on some issue, only research some way to solve a problem differently. Read up on some other things. Anything but focus on the issue at hand. And there are the hyper productive days where you forget that people exist, that you should go to lunch, or that it’s already dark outside and you’re still at work. Either situation is worth concern, if it continues for too long, and neither situation can be detected by a time tracker on your issue.
Suck 3: Metrics
You have statistics, which are a very finite form of metrics, dealing with the past. But when you’re doing project management, you’re more concerned about the future. You want to know is your project on schedule, you want some kind of prediction when the project might end on the current burn rate, you want some kind of indicator which tells you that you might face delays or go over some magical quota of issues you can track with available resources.
Is your backlog piling up, or are you allocating too many developers to handle issues? Think of it as managing a fleet of cars- you should have enough of them to handle demand, but not too many so they are not staying empty for too long. Good metrics should answer this question.
Usually, you end up tracking too much, all the data is useless in the sense that it’s unreliable for any kind of prediction, and your only anchor is what is completed. Let me stop here and just say it sucks. It sucks because it’s not actionable. If anything, issue trackers provide vanity metrics in most cases.
Yeah, fine, I see that issue tracking sucks
But everybody does it. The main problem with issue tracking is not tracking issues. It’s a people problem. I organize my tasks into a way that works for me, while somebody else has a different management approach to it.
How would I solve it? When it comes to having an issue tracker for providing support via web, e-mail or telephone, a help desk system for your clients or end-users, you’re not solving an organizational issue — collect as much data as you can, without overloading the person who reports an issue. The most important KPI in support is speed. The faster you respond with a fix for the issue, the happier the customer/client.
And when it comes to software development — if you’re not exactly a freelancer, create issues for other members of your team. Creating your own issues might mean that you don’t list some information which might be obvious to you but not to somebody else. Communication is a strong factor in effective issue management which is often overlooked or completely ignored, especially when there’s just one captain at the helm.
Keeping issue tracking “thin” while at the same time providing valuable data is key in my opinion. You want just enough data, that you’re not overloaded, and you want the data to be actionable. Sometimes, making the metrics available to developers themselves (and not just management folk) is very useful in the sense that they can do auto-correction when they see some tasks drift. And who here likes issues which get solved without them?
What can you do?
My experiences are my own. I’m interested in what ways issue tracking sucks for you. Please take some time to answer a questionnaire about what you use and what does/doesn’t work for you. If it all works out, I’ll assemble a team and give it a shot at the 7th issue tracker. I think it can be really good.
I’m have passions for several programming languages, PHP/Node.JS/GoLang as most current examples. I take care of dev/ops at RTV Slovenia (Slovenia national TV/Radio station), I’m the founder of Monotek, and I’m writing a tech blog at scene-si.org. You can follow and ask me questions on Twitter.
