Issue trackers considered harmful for tracking product development
kitemaker.co
kitemaker.co
I’m going to call them bug trackers from here on, because I don’t like the name “issue”, which I find an insipid term that’s kinda part of the problem.
Generalising and simplifying (to the point of at least mild inaccuracy), bug trackers are excellent in open source work, but work trackers and planners are more useful in business.
Also a remark of my own: bug and work trackers both have a painful tendency to slowly increase in scope and try to cover each other’s purposes, but poorly. They’re similar, and there’s definitely some overlap, but they’re quite different in how you treat them, most of all in how you maintain them. An automatic stale bot may be reasonable in a work tracker (though it’s not ideal), but has absolutely no place in a bug tracker. (I have various comments on HN up to +76, and one outlier at +283, https://news.ycombinator.com/item?id=27274146, showing that lots of people agree with me in hating stale bots on bug trackers.)
Actually, what am I saying? Not just such trackers, not even just software, but human endeavour in general tends to scope creep and the problems that arise from it.
And yeah, the title was written in a way to be a bit provocative, but also pointing at that many (maybe most) teams use issue trackers for their product development flow.
I might perhaps title it “bug trackers aren’t good for tracking work” or “bug trackers aren’t good for product development workflows”. I like literal and direct (and often verbose!) in my titles.
Either this doesn't express the intent properly, or it summarizes as 'you call it issues, we call it work items' i.e. not really a difference. From the screenshots it also doesn't really look too different from other software I'm using (work items, like in other issue trackers, have labels and priorities and members and so on, can be put in a roadmap, etc.). My takeaway would be: if you want me to sign up to try this, you should highlight differences with say Jira/Gitxxx premium/...
So you'd like to see something along the lines of "in Jira you'd do it like XYZ, in Kitemaker it'd look like ABC"?
We should be focusing on what we plan to deliver to our users, regardless of the size. This is at the center of “outcome” before “output”
What I'm struggling with is seeing exactly how tracking a huge, "fluffy" outcome would be an improvement. For example, at my work we recently got a fairly big customer. As part of that, we will need to integrate with about 30 of their systems as well as implement a new API for them to send data to us.
Reading what you've written naively, it seems to me we should have a single "Integrate customer Foo" task to track. Without further details, I struggle to figure out to what degree this would be an improvement to what we're currently doing, which is using JIRA issues for high-level stuff like "integrate with invoicing system A", with a bunch of sub-issues for the details.
It could very well be we're missing out on something amazing, but without any concrete examples to compare to what we're doing, it's hard to determine. At least for me.
But I honestly don't see the fundamental difference between this tool and, say, my Gitlab issue tracker. Not just from the home page but even going into the guide. You have work items, Gitlab has issues (funnily enough, I was just reading before that Gitlab is migrating under the hood to "work items" to integrate issues/epics/incidents into a single entity), both can break down a single item into multiple ones, have a collaborative document at the top, an activity feed, roadmaps, labels... I don't what's the feature that would make me migrate development workflow to yet another tool (with more costs possibly, because 100 work items doesn't look like much if you deal with multiple projects).
Easy one first - pricing. It's always a challenge but we try to find something that's reasonable when compared to the competition. We're not big fans of tools that do limited time feature stuff (this feature only works for the first two weeks unless you pay) so this is what we're trying for now. We're very flexible with teams as well. If they don't feel like they've gotten a fair chance to try it out, we raise the limit and let them keep trying for free. We'll gladly take your money once you're satisfied.
With regards to GitLab or any other traditional issue tracking tool - if you're able to get this sort of a workflow where your team is really focused on the outcomes and not mechanically processing tickets, then that's great! We're not building the only tool in which this is possible, just building a tool that we feel does a great job of nudging people in the right direction.
I'm actually a CTO and product manager. We use Asana for high level planning and github issues for tracking detailed technical work. We design using Figma. Our developers don't go near Asana generally. We have our roadmap and backlog in Asana though and we track some non technical topics there for e.g. management, hr, sales, support, etc. It's good for high level stuff and usable by non technical people.
And since I'm in charge, this is an Atlassian free company and that's not an accident. I can work with their stuff but I prefer using the tools I mentioned over their stuff.
The reason I like github issues for product management is that they are easy to connect to pull requests and you can close them by mentioning them in commit messages. This cuts down on process bureaucracy, which means less work for me. IMHO any issue tracker needs similar deep integration with the development process like that. End to end life cycle tracking from inception to deployment for any feature and enhancement is key.
I also love using meta tracking tickets where I can easily convert TODO items into new tickets, refer existing tickets and PRs, etc. From a project and product management point of view that's great. Labels, milestones, etc. make this easier. And of course being able to use Markdown everywhere is nice too.
It's not perfect unfortunately and I'd love a unified ui with tickets from all our github repositories. Their project tool is a weird one; on paper it could do that. But it seems unable to do any sensible integration with the issue tracker unless you configure a lot of actions to copy things over which seems madness to me.
We try to explain how the design of issue trackers fail to address the needs of how best practices of product development are described by certain authors (Marty Cagan, John Cutler, etc.). I think we support everything you mention here, but at the same time removing some of the hurdles that many teams experience in getting an empowered team to work well together.
I've used everything from post-its, spread sheets, text files, jira, and all the rest. It doesn't matter what you use; just how you use it.
What I value is low friction usage. It's why I hate Jira because all the key operations involve modal pop ups and a generally high level of friction, lots of waiting for stupidly slow APIs, etc. Sucks all the momentum out of any meeting where you want to focus on content rather than stupid tools. What I explain in 3 seconds shouldn't require 3 minutes to mirror in the tool. It's what I love about Asana. Because it's just type, enter, type, etc. to create issues. Multi select with the arrow keys or control clicking, and boom labels, assignees, etc. added. That's low friction.
GH issues strikes a good balance. Create a ticket, add some checkbox list, convert individual list items to issues by clicking them. Nice. Could be better but it works.
I have zero experience with Kitemaker, so I'm not going to criticize it. But to me it looks like just another tool. What's so great about it? The article just descends into a nonsensical and completely artificial distinction between issues and goals. Why not do both? Why have two tools? Sounds like friction to me. Or impedance mismatch.
I actually have a closed beta on a product that allows you to have a unified ui for tickets across github repos. Perhaps it'll be a good fit.
This is where everybody would expect a screenshot, or at least a detailed comparison with the competition. Since you mention "Epics", you clearly have a certain competitor in mind: you don't need to be vague.
When you start something new, it's not a big deal. Everybody loves to work on something new. Nobody loves working on legacy products, because they don't have enough documentation and full of bugs, driving up costs of support and becoming a pain in the ass of some CIO. Yet somehow all those fancy new tools focus on creating great experience for building something new. Plenty of decent software was written in the last 50 years, but we are burning the money, electricity and silicon to replace it, because we could not come up with methods and tools for building on top. Why it is always about integrating something like requirements and context into planning? Why not doing it the other way, integrating planning into requirements and context, being product-centric rather than work-centric?
One thing people tell us they like about Kitemaker is the ability to have a historical view of things. Because all of those extra edge cases that pop up get captured right in the same work item (and because we have an activity and history view on the work item), it becomes a pretty good place to explore the history of how you ended up where you did instead of a bunch of disconnected design docs and tasks in an issue tracker.
Thank being said, your comment has my gears turning on how we could do an even better job of it.
Good referencing model of course helps to navigate in reverse direction too, enabling engineers to understand the context of certain parts of the code.
They can and should. And it turns out that teams can improve an existing task writeup simply by adding an explicit outcome goal and metric, such as: "Aim for outcome X as measured by Y".
The way we're structuring things in Kitemaker (large, collaboratively edited work items) is an attempt to prevent that. But of course it's not the only way to achieve it.
Awesome if you can make it work in your current tool of choice! As the article mentions, another way teams have solved this is by augmenting their issue tracker with a document-based tool like Notion or even Google docs and motivating their team to stay on top of those outcomes.
The former is using it as a tool, while the latter is using as a way to control.
But these headlines pop up everywhere and, at best, present an opinion, usually of one person who neither surveyed a large group nor has the authority to make such claims personally.
I might write an article "Articles \"X considered harmful\" considered harmful".
People were annoyed by those and wrote such an essay at least 20 years ago [1,2] (possibly there were others). Didn't help much, but generally fighting idioms/memes/fashion doesn't seem quite productive: perhaps it's more useful to focus on not being frustrated by those (and accept the way this phrase is used).
Edit: Though ranting about titles on HN is still a fine activity, not trying to discourage that. Just an idle musing on being more content with those.
[1] https://en.wikipedia.org/wiki/Considered_harmful#Snowclones
The point we're trying to make is that a tool can help nudge you in a certain direction, and we're trying to make Kitemaker the tool that nudges you towards working in a way that gets the whole team focused on outcomes instead of focusing on small tasks.
If teams are able to achieve that in their current tool of choice, that's ok too. We just believe working in this way is healthy and productive and hope to see more teams thinking along these lines.
Using issue trackers to track bugs is great.
My solution was to manually maintain a bulleted list of links directly to the relevant issues.
Most obvious example ? Stale-closer bots.
I mean, sure it makes you look good because you have a low number of open issues.
But its basically 21st century sweeping under the carpet.
Maybe there's a bit way to surface these old things and remind teams to deal with their skeletons.
Ah, so they're impartial, and this isn't clickbait at all.
Most of the points raised in the article are opinions based on a limited understanding or use of issue trackers. For example:
One can easily ask, "why can’t issues represent outcomes?" They can, but they are not designed for it
Issues typically have only one assignee.
They don't give you ample space to describe the problem and solution
Issue trackers focus more on metadata and workflow than on supporting the team in collaborating, reaching decisions, and shipping to our customers
Some issue trackers will even actively suggest scoping issues to be as small as possible, which is the opposite of what a sound product development framework will suggest
First, we should be aware of the shortcomings of the issue tracker. [...] The challenge is that you will end up tracking work in two systems.
That's exactly the point we are trying make. Issue trackers are good at tracking issues, but now people use issue trackers to track everything, from product development to task tracking, which they're often sub-optimal for.
> Yeah, because there is a lot of complex and different kinds of work out there, and building one system to do everything is a bad idea. A carpenter has multiple kinds of hammers. That's not a bug, that's a feature.
That's the bit I think we disagree on. My co-founder and I have both managed very large teams at large organizations. If you start splitting up everything into different tools, suddenly product is entirely disconnected from development and vice versa. We've seen it over and over where a tool becomes a "PM's domain" and is totally disconnected from the reality of the developers' work.
Now obviously you can make it work with discipline, but you can make anything work with discipline. We think Kitemaker makes it easier for product/development/design by creating one place for them all to meet. I agree that there are different types of hammers, we do not try to replace git/figma/slack but rather integrate with them.
I think we mostly agree at a high level, we just disagree where the split should be between different tools and you don't like the click-baity style of the article (that's fair and we'll try to work on it next time)