I appreciate how clearly it is written down. It is how I would like to work and have tried at numerous jobs.

I do find that reality is hard, though. There's always that moment when you don't feel like picking "the one at the top". Maybe because you have time for "a quicky" maybe because after spending a week on Foo, you now want some Bar?

What this also does not solve is the "panic shifting". When a business goes into panic mode (deadlines, rough patch, downtime, chaos) you'll often see that tickets get moved from underneath you while working at them.

- Holdit, I'm done 80% with that SuperImportantEmergencyBugfix. Can I not finish and deploy it? - No, there now is a SuperEvenMoreImportantEmergencyBugfix that has to be fixed two hours ago.

No ticket system will fix that, but anything that helps with those moments is very helpfull, I guess.

Interesting read - to a person working tickets, I think it can be true that there is no useful difference between viewing a task as a bug vs a feature - in either case, its "what needs to change" and performing work to do the change.

However, the big difference to people not handling the ticket (the customer/business + the person(s) who have to deal with bug accountability) - a bug usually represents a failed promise and is quite different from a feature.

If I go to a restaurant and there is a "bug" in my order, I expect it fixed for free, so that in the end I'm getting my original order (with the extra work/time requirement eaten by the side which erred to begin).

If I want to change my order because I don't like the food after all, then that's not a bug, that's a change in requirement/feature request.

Having bucketed priorities (highest/high/medium/low/lowest) is a big failure of Jira / ticketing systems though. They should be a unique set of priorities, with only one single ticket occupying #1 priority, another slightly less one in slot #2 etc.

> One way to recover is to automatically close tickets after a certain period of time.

Just be thoughtful about how you do this otherwise it can easily come across like "we don't really care about your issue".

Google has had two rounds of auto-closing old Android bugs and their message is really bad. Something like "Our product team is prioritising other things.".

Similarly Github's stale bot is way over used. One project I submitted a bug to closed it because there was no activity for only a month.

If you must close old bugs automatically, word it nicely, and don't close it instantly and ask people to reopen it. Something like this is best:

> We're trying to clean up our bug tracker. This bug is older than 5 years and has had no activity for 2 years. Is this still an issue?

Compare with Google's message:

> Thank you for your feedback. We have tried our best to address the issue reported [they hadn't], however our product team has shifted work priority which doesn't include this issue [what does that even mean?]. For now, we will be closing the issue as "Won't Fix (Obsolete)" [great, thanks]. If this issue still currently exists, we request that you log a new issue along with the latest bug report here: https://goo.gl/TbMiIO and reference this bug for context.

The central point that work trackers track work is true important and jira astronauts need to be stopped, but the piece misses the bureaucratic purpose of jira: work legibility.

Work tracking isn't just about figuring out what work needs to get done, it's about helping management get a picture for the state of work.

Developers and other line workers don't care about obsolete vs won't do. But management does. They want to know if they're being requested for work that will be rendered useless in a few weeks. They want to know if too much work isn't getting done because work is floating up to the CEO and it's not worth his time.

There's a terrible principal agent problem here where management, the principal, decides how to track work, and can put the heavy lifting of filling in values onto the developers. This happens when management's more worried about losing their job than improving their team's output.

This post solidifies an idea that’s been kicking around in my head: software tends to push productivity towards a local maximum.

Let’s say the author is right and ticket queues should be a single stack with no priority. That seems pretty easy to make. Easy enough on a popular enough topic that I’m sure it’s been done. But, I’ve never seen or even heard of one in use. Why? Because it forces people to make hard choices. The software doesn’t handle all the real world crap that comes up when people try to use it. It can’t make the jump out of the local maximum. So instead, we get people endlessly iterating on the same ideas and releasing the same basic project trackers with slight twists.

Also, I think there’s a billion dollar company for someone who can make an internal support tool that people will actually use.

This sums up why I like Kanban.

The TODO column is an ordered list of things to do. The job of the developer is to pick tasks from the top and move them towards the right. The task of management is to keep the TODO column sorted, and prevent tickets from being stuck in any other column.

The task of management is aided by limits on how many items each column contains. Those limits are based on how many things people can realistically do at once.

It's odd to me that the proposed Minimal Skeleton for tracking a bug doesn't include:

* who reported the issue * what they reported happening * what they expected to happen instead

For many reported bugs, it is clear what the actual problem is and what needs to be done to resolve it. In this case, it can feel like unnecessary overhead to track the bug in a separate system from the rest of the development work queue.

But it's worthwhile to have a place to track bug reports that can't yet be acted on by writing code. Sometimes it's not immediately clear what is happening or what should be done about it. Sometimes you need to reach out to the reporter(s) for more information or to let them know progress has been made.

Even with well-understood bugs, there can be a many-to-many relationship between the bug and the development work to be done. Sometimes you have many people reporting the same issue in different ways, and it's not initially clear that there's a shared root cause. Sometimes one bug report is best addressed in multiple phases of development work.

I'd argue that there's always someone who's managing all of the above, even if they're not using separate bug tracking software to formally do so. But as a team grows, making the investment to "show your work" a little more can make it a lot easier to collaborate and delegate.

This describes Pivotal Tracker almost exactly. You can go into it cold turkey, but to get the best use out of it, it helps to be familiar with the Pivotal software development process.

The important thing to realize is that pivotal tracker is not a "bug tracker" in the traditional sense - a giant database where issues go to be forgotten until someone clears them out in batch three years later. In the Pivotal process there is a product manager whose primary responsibility is curating the backlog. There are no priorities, just position in the backlog. The PM should know what's in there, that's their job - they don't write code.

Engineers just grab stories off the top of the backlog.

> there should be an algorithm that everybody should agree on. An example may be:

> - If there is downtime, it’s the top priority of everyone affected

> - If there is an incident, it’s the top priority for an on-call agent

> ...

Very much agree about this.

The trouble with "high priority" and "low priority" etc. is that different people perceive different things as having different urgency and importance. As long as you have >1 person entering tasks, each using their own algorithm to assign priority, a "sort by priority" (the only point in having a "priority" field at all as far as I can see) becomes completely useless.

If you use names like "downtime" or "incident" then, as the author writes, everyone can agree. That's the important thing I think. Then a "sort by priority" can yield something meaningful.

Plus there's the fact that when you have pages of "highest priority" tickets, managers just create all new tickets at that level, "otherwise they won't get seen and done" (true story)

This way of working annoyed me so much I wrote a blog post about it: https://www.databasesandlife.com/priorities/

Super interesting, I like how the minimal skeleton for product development has been broken down.

Overall, I'm mostly aligned but it seems to me that it's very focused on low level product delivery. I feel like it's ignoring the bigger picture of how these "tasks" come to life and where they go after they're shipped.

Shipping software is much broader than moving tasks from "to do" to "deployed". If that was it, then yes, all you need is a flat & ordered list of tasks with an assignee for each. But it's not:

-How do you decide what do build in the first place? How do you make sure you are working on what's most meaningful?

-When you've prioritized the right problems to solve, how do you collaborate to come up with the right UX?

-How do you perform user research and user testing to validate your assumptions?

-How do you handle the feedback inbound you receive from stakeholders and customers? How do you take these inputs into account in your prioritization process? How do you then complete the feedback loop?

-How do you work with customer success and marketing to ensure everyone is informed of what you've shipped?

-How do you balance demonstrating product velocity while working on meaningful projects that take several weeks or months to ship?

What I'm saying is there is a broader context to shipping software beyond "accessing a prioritized list of tasks and getting them done". It's good to climb fast but if you're climbing the wrong wall, you're just getting to the wrong place faster.

That's the reason why my co-founder and I built Cycle (https://cycle.app/) – an all-in-one tool that helps engineers, designers, and product people to better collaborate in the process of shipping good stuff.

One missing thing: maximize the number of things that can safely avoid going through the bug tracker, because the tracker represents overhead and (even more importantly) latency.

Does that marketing website typo fix need to go through the development team and require a ticket? There are reasons it might, but fixes will never really be fast enough if it does.

Or worse, what if a developer has to ask someone to create a task and add it to the board to add documentation to a method? Then either no will ever document anything, or they'll sneak those changes into other tasks, slowing down code review and feature development.

One way you can create those pathologies is to have auditors, and promise the that "all code changes follow a process" and soon you're signing forms in triplicate to make any kind of change whatsoever.

Github issues works pretty well for almost all software projects. A single list of issues viewable/searchable by the whole team, simple commenting, code referencing, tagging, assigning to people.

We tried Jira but became tangled in a mess of complex configuration and endless confusing UI's...

Almost certainly what you can fix and release in an hour has higher priority than something that is going to take a month, for example.

I have had quite a bit of success in having the technical teams assess the length of time a fix or a feature takes to do, but letting the stakeholders determine the relative priority.

I have seen requests and suggestions go from completely critical when requested, but when estimated at a couple of work then broken down into multiple much easier and clearer tasks when the stakeholders are included in the prioritisation discussion.

My experience is that stakeholders much prefer having things turned around quickly and they will what they can to optimise for things that are quickly and easily deliverable.

> There is one good argument in its favor [closing tickets that are too old]: the software continuously changes and hence old issues may be invalid. In order to put them into a sprint, they need to be checked—in some cases, that’s actually more work than the issue itself.

I agree this is sometimes true, those difficult to reproduce tickets often mysteriously disappear when you make other changes. But there are lots of times when a lot of work has gone into creating the ticket so there is actually not much left to do to fix the issue. In this case closing tickets that get too old would be very counter-productive.

It sounds to me like you're describing Pivotal Tracker (https://www.pivotaltracker.com/). It forces story ordering (rather than "prioritization"), it's pretty barebones, and it's fast.

For me none of the SaaS bug tracking systems are usable. They're all much worse than c. 1996 Bugzilla.

Nice, this highlights a lot of issues I’ve seen with teams and crazy bug systems.

One difference I had from the article is that I actually find marking tickets with priority and types (like bug / enhancement etc) useful, but for a different audience.

When I’m working on planning / strategy, aka in Product Manager mode, I like to be able to review what is still remaining in different buckets and adjust priority and do scenario planning. Maybe it’s worth closing a whole bunch of low priority bugs before moving on. Often the priority changes over time and gets adjusted as we see what came in. Having a place to track that info on the ticket keeps me from moving to doing planning in a spreadsheet.

When I’m in developer mode, I agree - I don’t want to have to think about what the priority of a critical feature improvement is vs a low priority bug. I want to pick off the top of the stack and flow with confidence.

I often am working in both roles on team projects and use this technique even when working alone.

In my experience where things get weird is when the product planning metadata is required to be understood in real-time by all roles on the team. You can keep all that metadata around and still have a single prioritized backlog.

Maybe Jira could be improved by showing different metadata for different modes... but even writing that out sounds like a new configuration nightmare!

Dont use todos or tickets or issue trackers! It takes too little effort to write a todo/ticket item. Your engineers will spend time doing work that are unnecesary and they will spend hundreds of hours implementing shitty ideas that only took 10s to come up with. Instead write down a project plan, write down the vision of the product. Write down what your goals are, and what you stand for.

> One way to recover is to automatically close tickets after a certain period of time. This may be a subtle way of saying “no”, but I think it has its place, especially if we are talking about public trackers.

Ugh, RedHat bugzilla trauma is coming back to me. Report issue -> 12 months nothing -> bug closed because new RedHat linux version was released. Repeat.

This is close to how I worked for years (mine: build a dependency graph and then order by dependency, work through a graph at a time). It caused a ton of friction with my work environment which was managers prioritizing bugs and then expecting you to work on them in priority order which, often, was nonsensical.

> When people scream “this is a bug”, it is irrelevant what it is caused by. It is a scream of a significant expectation mismatch. The team should work on resolving it, regardless of whether it was caused by a developer diverging from the designed intent or because of the original intent going wrong.

As a user, it's extremely relevant to me. I paid for your product/service because of what it claimed to do. Bugs are ways in which it doesn't do that. (It doesn't matter to me if some other hypothetical features don't exist yet, because I was happy to pay for the product/service knowing it didn't have those features.) As far as I'm concerned, a bug is your company not holding up your end of the bargain, even though I've held up my end by paying for it. That's not a good look.

Another way to look at it is that a bug is downtime for a feature. Elsewhere, you say (system) downtime should be #1, "top priority of everyone" until it's fixed. But what good is the system being 'up' if it's still broken in the way that I need? When I lose power at home, it's no consolation to hear "The power grid as a whole is still up -- it's just your neighborhood that's not working", nor would I consider this reasonable justification for de-prioritizing fixing it.

Maybe your company is at the stage where attracting new users with features is more important than keeping existing customers with quality. But they say it's always easier to keep customers than it is to acquire new ones, and I've blackballed several companies because they no longer place the priority on quality that they once did. You should be aware of what you're giving up by de-prioritizing 'bugs', or pretending they don't exist. I see comments here on HN every day complaining about specific companies whose software quality suffers. It takes years to dig yourself out of that hole.

From my experience in 5 companies at various stages, engineering task management in whatever form is generally efficient until you hire your first program manager. This happened several times regardless of team size. The engineering manager/director/VP gets tired of his work and takes a break by hiring a Program manager. PM’s sole job is to make sure the tasks management is shielded from the rest of the org but invariably, they overengineer the “process”. I am yet to meet a PM who simplifies things or makes things more efficient.

Something this article completely overlooks is coder mental health. Working on bugs constantly is the equivalent of being a code janitor. Getting to own/run a new feature from time to time can re-invigorate your interest.

The suggestion I put out at an old company (which was shot down) was the idea of owning features. If all the bugs for features you own are resolved, pull a new feature. You now own the bugs for it.

It gets difficult when a feature is too big for one person, or too important for that developers bugs to be a blocker.

In general tickets describe change requests, and they are sometimes referred to as such (CRs): Someone wants the software/system to change in some way.

A ticket type makes sense because bugs and new features are not the same and we should care about the difference. A bug is a defect in the implementation of a feature that should be fixed. A good practice is to fix defects before adding new features, as far as possible. A defect is discovered on a specific software version so it then makes sense to indicate that. Even with continuous delivery it is useful to know exactly what build exhibited the issue. Having explicit information on whether a ticket is a defect or a new features is also helpful for QA (as is severity): I need to keep track of the number of defects found in order to somehow measure the quality of my software and of my testing and to improve it.

Assigning a priority makes sense because it helps setting the ticket's position in a queue (which can be called TODO list).

Severity is not the same as priority. Severity is the impact of a defect. A defect that causes the application to crash and delete all data is very severe. A typo is likely not a severe defect. Again that helps in assigning a priority and thus how to insert the ticket in the TODO list.

The position in the TODO list is not an input it is an output of the task that consists in analysing and managing the pending tickets.

You could say that a dev is a worker task that picks the next ticket in the TODO list in a loop, while a (project) manager manages the tickets and insert them in the TODO list.

With the small caveat that this is scale dependent. I can assure you that there absolutely are projects that require components. (If you prefer a different model, you can assign a different bug tracker for each component - but that makes collective metrics harder)

I agree that ultimately (and quickly) the bug needs to land with a single person, but the component matters in the routing step before that. Because you'll have frontline triage who can only vaguely figure out where the bug goes, second-line triage might get the team right, and then the team needs to decide where it goes.

Yes, that's a lot of overhead. Unless you have 1000+ people working on your software, you won't need it. Up to ~100 people, you can probably assign fairly directly, depending on the range of problems the code base spans.

Similarly, there are reasons why you don't want to do task breakdowns for everything in the bug tracker. Global refactorings are a good candidate to skip that, because you will do that across teams, piece by piece, and tracking them in a bug tracker is not necessary. We got spreadsheets for that ;)

Same goes for priority - sometimes you do need it. That zero-day you're fixing is a "drop everything else" bug. And really, the "flow" is just nine different priorities. (God, let me never work on something that has nine different priorities ;)

So, "season to taste". But there are definitely lots of good ideas in there. If there was just ONE I could enforce across all projects I ever work on, it'd be "Close the damn bugs if you're not going to work on it" - issue hygiene is incredibly important.

I enjoyed and mostly agree with these ideas. Some points though:

Re: Position In a Queue

> Every team must have a single ordered queue of tasks > every single one of them is prioritized relatively

This may lead in Eisenhower's matrix to prioritize urgent tasks vs important tasks and end up with tech debt.

I lead a soft eng team and we have a task queue but they are not prioritized (and that may be a mistake). Beyond the time wasting agonizing if X > Y for tasks, I like to keep parallel tracks of urgent (blocking) and tech debt tickets.

Re: Ticket Type

The most or one of the most important metric in software is user angry or happy calls (a proxy for revenue). If an unannounced planned feature doesn't make it to the next release, nothing happens. But if the customer now sees a regression bug (something that worked suddenly doesn't) that's bad. There's value in differentiating bugs from features, at least in some industries.

Re: Software Version

See Semantic Versioning https://semver.org/ ; it's important to know if a release is backwards-compatible or not

I'm going to add to the pile-on that the "Ticket Type" field is a little more useful than the author gives it credit.

> why do you want to have this information and what is it going to be used for?

You might say this is yet another proxy for priority, but it's slightly more nuanced than that. A lot of software companies do not have the experience of continuously deploying the main code branch. I work on a SaaS solution that's gained traction in highly regulated industries.

It's very useful to be able to identify (trends in!) bugs that could be described as a "regression" or breakage in behaviors that customers are known to rely on. This isn't the example of "Customers" from your post though, ultimately how the change gets prioritized and released is what they care about! This is about being able to identify and systemically manage change in high risk areas.

Much of this is only from the perspective of the consumer, a developer.

What businesses want is a way to be able to track progress and communicate priority.

The difficulty for the the business is how they communicate their priority to you, that's what the priority field is for, it's a way for the person raising the issue to supply a way to communicate how important an issue is to you.

The position in the queue is how you (and presumably your team) should decide what order to tackle the work in.

The final point is the solution to the problem is to create another system for issues, which goes against the point that says "every team must have a single ordered queue of tasks".

I find it interesting that the solution to, in their own words, "One of my life’s traumas" is to add another issue tracking tool.

Are we trying to fix the right problem?

Web readermmode: https://baitblock.app/read/https://almad.blog/essays/no-bugs...

Great quote from TFA:

> Once you start assigning priorities from a list, anything else than “Highest” is a passive-aggressive way of saying “No”.

What can be gamed will be gamed. Once you start applying the equation "feature = good & defect = bad" or assigning arbitrary priorities "high, really high, now, yesterday", you are in effect providing opportunity to game the system.

Story points have this quality. More points are good, less points are bad. Let the games begin.

The value of a ticket / work-item comes strictly from the changes made to the underlying system. The "diff" effectively. The labels and types that we assign to work-items don't actually add any real value to the system.

There’s a great tool - pivotal tracker - that acts in the way that the author describes. It’s great because it’s opinionated.

It also includes pretty good PM tools like burn down charts, predicted velocity, etc.

> The toolset that completes the version control log to form the development equivalent of double-entry bookkeeping.

This made me wish for a "git commit --future" that lets you just track future things to work on within git itself. "git stash" is kinda connected into this concept as well, branches too if used as development caches. It gets a bit wonky with multiple repos, as well as non-code related tasks, but then we have a single location for tickets, and a UI could be created to connect with other teams.

I feel the same way about Asana and Jira. They're so customizable and cater to too many people that it requires management to be someone's full time job. And I haven't found someone who is passionately in support of such as service as you might find with say Notion.

I've been working on a project that is attacking this problem but from the TODO comments angle. https://cosmolabs.io

> When people scream “this is a bug”, it is irrelevant what it is caused by.

When people say things like this I often wonder if they worked with a more consistent caliber of people than I have.

There are most definitely bugs, and figuring out that most of them come from a couple of people is critically important to saving the project in the long run.

Knowing that you have 5 bugs and I have 7 is, I will agree, not important. But knowing that Steve has 50? Is really fucking important.

The Software Version field should be used to identify the commit when the bug was introduced (perhaps the very first commit that introduced the entire thing in which the bug is found or perhaps a regressing commit). The way it's typically used is not helpful: namely that the user who reports the bug just fills in the version they happen to be running when it happened.

There should be an Introduced-in Version and Fixed-in Version.

>>> Every team must have a single ordered queue of tasks.

No. Every organisation. All the politics, all the empire building and compromises just to get along are brought into the fore and must be solved to decide if projectX is above or below projectY.

Do that, and we might just believe you are a company worth working for.

We used the Ticket Type field with a totally different workflow. There was always one developer on each sprint whose task was to only bug fixes, nothing else. That person got the "Bug" Type tickets. It was always a mistake in existing implementation.

But if there is only TODOs and not bugs, how managers will prevent the creation of 'high severity bugs' when they're in panic mode? I wish I was joking but that's something to think about..

On point in so many ways... There is simply no way of decentralize prioritization. Thanks Almad, for sharing valuable insight/realization with the rest of us.

There are no "bugs". There are "defects". -- HP, back when they were good.

The website theme is nostalgic. Does anyone know of jekyll theme that generates such simple website?

There Are No Margins, Just TODOs

Upvoted for calling out "management by Jira". I hate that.

The small amount of padding in that page was a bit disturbing.

This idea is very clever:

“then ‘upkeep’ and ‘new’ should be the ticket types”

So there are no debuggers, just untodoers...

But if they're not called bugs, there is no blame game. And extra pressure can't be put on developers to . . . to shape up! Sense of urgency and all that.

There are no TODOs, just bugs.

There are no TODOs, just bugs.

> Assign to a single person.

That doesn't work in teams with collective code ownership, ie all successful teams. But you can replace this with "assign to a single team" and i think it works much the same. The footnote to this says:

> For larger teams, that can be a team account, but in that case, it is team leader responsibility to go through all team owned tickets regularly and delegate them

But that isn't correct. You can have a team pull from a single queue of tasks assigned to the team as a whole. There's no need to proactively assign them to individual team members.

> Every team must have a single ordered queue of tasks.

As long as you understand that "tasks" does not encompass technical housekeeping tasks like refactoring, improving the test pipeline, etc, sure. The queue of tasks needs to be ordered by someone with customer/business/domain knowledge. There's a negligible probability that this person is also expert enough to prioritise housekeeping against feature work. But the development team itself can do that, no problem.

> I advise to start with the “Todo”, “Doing” and “Done” triad and only add more if absolutely required

This sounds good. My one thought is that there are usually different people who can say "i think this is done" (the development team) and "yes, this is done" (product owner / QA / etc), so i suspect todo/doing/ready/accepted as the minimal set. But you could find a way to make three states work, i'm sure.

> When people scream “this is a bug”, it is irrelevant what it is caused by

It's relevant to estimating velocity. If over a quarter, you estimated you'd do a hundred features, but actually did one feature and ninety-nine bugs, you should not plan to deliver a hundred features next quarter.

It's relevant to continuous improvement. If you're getting a lot of feature requests, great, carry on. If you're getting a lot of bug reports, not so great, slow down and see how you can improve.

> Saying “no” is hard, but without it, the issue system becomes an unmanageable mess.

We must recognise this as simply being an expression of the author's deletionist aesthetic preference, not a fact about the world. As long as you know what the most important tasks are, it doesn't matter if there are an infinite number of less important tasks behind them.

> Yet I do believe this is actually a property of any job position: people rarely want their job to disappear. The moment you create a job position, it tends to metastasize.

Very strong truth! My third (?) law is that if you hire someone to do something, then that thing will get done regardless of whether it is actually useful. I am most often reminded of this law when dealing with security people.

It's cool! I agree ;)

There is a huge difference between a TODO and a FIXME.

A FIXME cannot be in master, but TODO's all the time.

There is no code, only characters