There Are No Bugs, Just TODOs | Hacker News Reader

There Are No Bugs, Just TODOs

almad.blog

510 pointsAlmad198 comments

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.

Our company became determined to control such panic-driven prioritisation, and had four simple levels of importance, P4 up to P1, a predictable conveyor belt delivering work.

Equally predictable was the later addition of P0. Followed inevitably by P-1. Sadly the company was bought out before we learnt whether the underlying datatype was a signed short or a long...

I've seen good success with having an entirely different pipeline for rushed/rapid/panic tickets. The rapid pipeline reduces some of the ticket and procedural bureaucracy of the normal pipeline, and only lasts a sprint. That obviously comes with risk, so putting something in the rapid pipeline needs to be weighed properly.

The somewhat untold benefit of this system, is it makes the product manager or client decide between "I want to control this ticket" and "This needs to be done as fast as possible". That seems to naturally filter out tickets that are only superfluously high priority.

This seems interesting but I'm having trouble visualising it. Would you care to elaborate?

Sure!

A standard ticket pipeline might look like this: Backlog > Review/Estimate > In Progress > Internal Review > Testing > Client Review > Feedback > Testing > Release

But the rapid pipeline will be more like: Create Ticket > In Progress > Testing > Release

This leaves the ball almost entirely in the developers court, and removes any step that requires waiting for feedback from the client or even the Project Manager.

So you can see the risk factors pretty quickly, with no review steps what if the developer gets it wrong? So that leaves the Project Manager some important questions: Is this ticket concise enough to be rapid? No room for back and forth discussions or muddy details. Is this ticket small enough to be rapid? Can't be a big new feature that's just being framed as urgent but could realistically wait. Can I trust the developer to get this right with no review? If you can't, then it's probably best it goes through the standard pipeline with the review steps anyway.

In big enough teams it can help manage workload, you can leave a specific developer intentionally under-utilized so that they have space for rapid tickets. During their under-utilized time they can be open for mentorship/learning/pair-programming until a rapid ticket pops up.

That is how all our tickets work. We have a lot of autonomy in that regard, put the product owner still sets the priorities

That is so familiar that I seriously wondered if we had crossed paths at a previous job. The only difference being our priority was the other way around P4 being the highest.

Basically all tickets would naturally migrate to P4. Eventually when someone started working on 'the wrong thing' another level was added.

In my current job we use Jira and the backlog has things at the bottom which have been just added, things at the top which we thought were priorities at some point and a whole bunch of crap in the middle which is unordered.

I keep thinking about some kind of system where people would rate the priority of one ticket against each other rather than against an arbitrary scale.

That’s the whole point of that backlog. The order should reflect the priority of everything relative to everything else. You drag stuff up above other stuff that is lower priority and part of everyone’s job is to groom that list so it reflects reality.

While that may be true in theory in practice it is difficult. A big improvement would be if new things needed to be inserted into the backlog at an appropriate place but I don't know if it's possible to do that in Jira.

This, I think, is exactly why everyone I know who is happy with their backlog management does it in an Excel spreadsheet or Google Sheets.

I'm fine with ticketing systems for handling immediate work in progress. Which, incidentally, is what they're meant to be used for. Every time I've ever seen people try to juggle business priorities and long-term goals in a ticketing system, though, the end result has always struck me as being something of a failed experiment to develop a product that works well as both an ice cream topping and an engine lubricant.

That ticket comparison idea is awesome. You could have it for one person, or do it democratically.

I bet there'd be circular comparisons (A>B>C>A) a surprising amount of the time. Not a huge deal, you could just show the pairings back again in a different order until they resolve.

I wrote a toy app when learning iOS that took the items in a todo list and showed you two at a time. You’d swipe the less important one off the screen. It built a hierarchy and you’d end up with the “most important” item to focus on. It remembered previous choices (or you could start over) to make finding the next item quickly, with just a few more choices.

It connected with the Reminders app and the Wunderlist API. I wonder if I could revive it with more services…

We've been doing that for a few years now. Basically we have two queues: The queue for escalated defects, and an ordered queue of about 10 prioritized enhancements that we've ordered based on what we think is most important comparatively. There is also a backlog of ideas/garbage work.

It works fine, except that the product is complex and old enough (and the team has too few developers so) that the bug queue rarely gets to zero.

This does not mean that having priority is not useful, this just means that they did it badly.

Everything is prioritisation. I'd say that prioritisation is one for the key skill of people leading organisations.

People who can't do it will fail whatever tools they use.

This works well in theory, until managers urge you to treat every task as "P-0" and you suddenly need to prioritize within the P-0's (we would jokingly use negative numbers instead).

In my experience, the relative queue _is_ helping with that since you can be explicit. If SEMIEB is really more important than SIEB, it's fair to switch—but it should be done as a relative comparison / override. I mostly saw people pushing SEMIEB without being aware what they are pushing down.

Although I would agree that if you have to reshift on hourly basis, this sounds more like oncall than normal dev work :)

Agreed on "on the top" not always being viable / feeling like it, but it helps when you go top-to-bottom consciously as opposed to randomly.

Priorities changing is one of the more frustrating parts of doing client work. Business priorities can change for so many different reasons, and you just have to learn to let go. I've seen entire product lines disappear the week a singular person leaves the company. Product in boxes, ready to ship, no longer needed.

If you are in an environment like this though, try to do very atomic commits as you go. Often you can salvage some work for the betterment of the platform even if the whole feature is not needed. Maybe you did some refactoring, if that's in a neatly organised commit you can just cherry pick it right out of there.

I think an important consideration is important for whom. If the only reason something is important is because of an arbitrary management deadline, the right response is to stand your ground and calmly finish working on what you already picked up. While I understand it's easier said than done, if you don't stand your ground, it won't get better. The polar opposite of this is when I personally broke something and it's stopping others from doing their work. In that case, the right response is to drop what I was or wanted to be working on and fix the issue.

An extra case of all of the above is planning work around big releases and the like. Regardless of how solid your CI pipeline is, if there's a bigger change set released, it's good to have someone who's designated on call. They're free to work on their stuff if they please, but their main priority for that whole day is the delivery. If anything is fishy, they're the guy who picks it up first.

None of the above happens without good communication. To get to good procedures you need to take the time, discuss with your team, and agree on what your plan of operation is. Make sure it's clearly communicated both inwards and outwards. If anyone internal or external comes to you with a fire, you can point them to your plan. It may be urgent to them, but that doesn't mean it overrides your team's agreements.

With all of the above in place, the scenario you described changes considerably: instead of asking whether you can finish your task, you will instead inform the other side that you're going to finish your task, and if it fits your plan, then deal with their problem. At the end of the day, it's a matter of mutual respect — it doesn't matter what the org hierarchy is, they're asking you for help, they can't demand it.

As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you want to stay employed rather than doing "what's right" and getting fired over it. Standing your ground if you don't have solid seniority first is about as ridiculous advice as a parent telling their 7yo to "just tell them to stop" when they're getting bullied. You don't have ground to stand on, and even if your input is right, and well reasoned, it can't come _from you_ because your voice has no weight.

By all means, try to change the system, but telling others they should too is advice from an extremely privileged position.

First i do what my boss says, when i did that and we both have a little time to talk, i explain to him why i was thinking the other stuff was more important, often he has a good point from a complete different perspective than i have, sometimes i 'win' from my 'technical' perspective, after some time passes you learn to read each other and decision's are made without questions, for me its super important to know each others and the base where decision's are made.

Yeah, the best you can do at that point is to meticulously document your work. You don't want to look unproductive and get fired just because you're constantly stopped from releasing your work. And in the case that you do get fired, you will want to give your lawyer some ammunition in the form of work logs outside of the ticket system, which you will be barred from.

I will usually drop a small comment saying 'deprioritized due to OTHER_TICKET_NAME' and mark the ticket as Done.

I sincerely disagree. Taking the extreme case you described as either do it or be fired, the other party wants a result, a task done or something similar, which still won't be done if they would fire you on the spot. It seems you misread my reasoning as blindly standing your ground which is not the case I was making. If there is a good reason to switch what you're working on, you should, as I also said above. But if there isn't one, you should either ask until you get a good reason or stand your ground.

The argument from privilege frankly confuses me. I've applied the same principles both when I've been the underdog and the one asking others and it's good guidance since it also gives you input whether you want to work where you currently are. Sometimes I've had harder times because of it, but I've never stayed in an abusive work relationship.

I remember when I had ~3 years of working experience. We were on the tail end of a fixed price/fixed date contract. There was a bug that needed to be fixed, and it was in a module that everybody had worked on, and the code was pretty bad.

So during the meeting, I said: that bug is just a sympthom, the module needs to be rewritten. And I knew what I was talking about.

No, said a senior, we're just going to fix the bug, no rewriting. I said that's your call, but I sure am not going to fix that bug. I can tell you: nobody listened to me.

So he more or less finished the discussion and said: I'm going to sit down with you, and we're going to fix that bug. And we did.

At that point it was the right call.

In that case there clearly is a good reason though? In the scenario described, you have one known bug, in the case of a rewrite you have an unknown number of bugs. Surely, both approaches may have more unnoticed bugs in them but in the former case people have already tested the solution so that's less likely. When you rewrite, you enter new untested territory with more room for new bugs.

Every junior and intermediate dev would like a word with that concept, because it sounds magical. Once you have a few years at an org under your belt, you have the creds to pipe up, but until then, you either talk with the better devs in private and hopefully convince them, or you do what your boss told you to do.

There's a great manufacturing-management book that regrettably speaks to a manufacturing context and not a project context and therefore applying it literally to our software projects would be a fallacy, called “The Goal”—and then the rederivation of the same principles for project management is in a follow-up book called “Critical Chain.” They are both weird in that they are textbooks written as novels and therefore you do have to roll your eyes a little bit, of course when the beleaguered manager follows the smart scientist’s advice his company succeeds and his marriage gets better, sigh. And why is it a he, both times? But if you pay the cost of these eye rolls you get some joyous moments.

For instance, your “panic mode” is discussed in The Goal (as “factories that seem to have three priority levels: Hot, Red Hot, and Do It NOW!!!”) and the emergence of those panic modes is actually diagnosed as a failure of those first principles. If you had managed differently, you would have been aware of your spare capacity, and this panic mode instead becomes a business problem of some sort—either you are not getting enough biz value out of your “SuperImportantEmergencyBugfix” project to justify continued investment of developer time or you are not getting enough biz value out of the EvenMoreImportant project or else you are getting enough business value out of both that it is time to expand your dev team so that your bottom line can get better sooner. But rather the panic is usually because the two projects are not profitable either way, and the company was willing to take a loss to build them up to profitability, but now revenues have gotten unexpectedly tighter and people are trying to fallaciously optimize on cost rather than marginal profit.

The Phoenix Project is a software instance of one of these textbooks-as-novels:

https://itrevolution.com/book/the-phoenix-project/

https://itrevolution.com/wp-content/uploads/files/PhoenixPro...

And Commitment is about software projects, and is a graphic novel (with a female protagonist!):

https://hennyportman.wordpress.com/2016/05/29/review-commitm...

I'm also reminded a bit of Simon Wardley's dialogues with X; these are just a roundabout way of him expressing his thoughts, but because they're structured as a debate, i think he gives himself a bit of unearned authority when he runs rings around his imaginary opponent:

https://twitter.com/swardley/status/1082647878349324288

The Phoenix Project has several main characters but arguably the main one is also a woman, as well as other characters (meaning not only one).

I need to reread The Goal again.

"people are trying to fallaciously optimize on cost rather than marginal profit."

Pure truth.

Another great book is The Principles of Product Development Flow: Second Generation Lean Product Development

In my experience, it worked better with Kanban.

The "top ticket first" approach forced us to improve knowledge sharing in the team. In practice, you can pick the second topmost ticket if it doesn't affect the schedule. You're a grown up.

The tickets you work on should not be based on your feelings, but on actual priority. In practice, if you feel like it won't affect the schedule, go for it. You're a grown up.

In my experience, panic shifting is more manageable with Kanban. Tickets aren't given arbitrary deadlines, so shifting them around doesn't change the order of work, but not the intensity of work. Bringing one ticket up pushes every other ticket down. Nothing gets squeezed into the sprint.

As for interruptions, it's a matter of urgency. Usually, Kanban dictates what you do next, not right now. There's also a limit on how many tickets you can have in progress. In practice, it's up to you to decide if a task is urgent enough to interrupt your work. You're a grown up.

For well-defined tasks, I love Kanban. Many people don't. But I think there is a lot of value in having a limited number of tickets "checked out" and having a quick, regular discussion on how the current state should be updated. It is also, in my opinion, the simplest way to "be agile".

It's also not compatible with complicated work. If you're still in the discovery phase, sometimes it takes a significant amount of work to get to a point where you really feel confident on what the end goal looks like, and how to estimate how you'll get there. In that case the work is shifting under you too much for Kanban to be of much help.

Time for a quicky is always good to have. When I don't however, I usually take that "annoying" task and see, whether I can divide into sub tasks. Divide and conquer often helps. If that does not work, I make a list of steps, which I need to take to accomplish whatever the task is about.

The panic shifting thing is real, and for me way too many companies operate in permanent panic. I'm fine with responding to actual crises. But so much "urgent" work is really just managerial failure. Fake deadlines used to "motivate" people. Broken processes that people work around. Executives urgently need to look like they're doing something. Easily solvable problems festering until they become crises. Managers rushing to score points, or to cover up for earlier neglect.

If everything is urgent, nothing is urgent. Even in an early-state startup, where urgency abounds, it's possible to work with a measured pace and clear focus. I've done it! https://williampietri.com/writing/2015/the-big-board/

The fact that larger, more stable companies fail to create order is not because it's impossible. It's because the people with power either don't care or have interests that actually work against getting things done quickly and reliably.

> people with power either don't care or have interests that actually work against getting things done quickly and reliably.

This is what I have seen, time and time again. Decision makers don't work for their employer, they work for their compensation package. It's amazing what one can rationalize when one thinks it might positively impact some number that's mechanically tied to one's bonus.

I've also seen it arise as a simple "too many cooks in the kitchen" situation. Ironically, the one thing from Scrum that I like without reservation is also the first one to get thrown out the window: the idea that exactly one person gets to decide the development team's priorities. Because if you allow n people to collaboratively allocate a scarce resource, they will allocate it to n * 100%, every single time.

Agreed. Although it's possible to get people to collaboratively agree on priorities. I've had a lot of success with putting stakeholders together at at table, making them write down what they want on cards, and then saying, "Ok, put them in strict linear order of delivery." It helps to give them a bunch of cards with "RELEASE" written boldly on them.

I once did this with 25 people representing a dozen different nonprofits, and I've done it many times at both startups and large companies, so I know it can work. Every time, people try to put things side by side. But if I gently say, "strict linear order" enough times, everybody gets it. And then they start discussing, negotiating, planning.

Another approach, one that works if your teams are established enough that you can give good engineering estimates, was what Rob Fan at Sharethrough used for quarterly planning: https://www.slideshare.net/rfan622/launch-scale-presentation

Basically, they gave out poker chips that represented the available engineering capacity for the quarter. And then had everybody discuss and persuade until they arrived at a quarterly plan.

As you say, the trick is to have some way to make sure people don't overallocate, which they dearly love to do. With that in place, stakeholders stop fighting with engineering and instead wrestle with one another, letting engineers quietly get on with popping things off the backlog and shipping them.

> [...] the one thing from Scrum that I like without reservation is also the first one to get thrown out the window: the idea that exactly one person gets to decide the development team's priorities. Because if you allow n people to collaboratively allocate a scarce resource, they will allocate it to n * 100%, every single time.

The way I've always tried to solve that is to have a single person (often a team lead, unfortunately) become that singular frontman, who listens to the n parties but is the one combining their input into one decision. That is, take away n-1's access to edit the issues, tell them it's an internal tool, and they should talk to the one person. And if you disagree with the frontman, that's between you and them, not between you and the issue tracker.

This really is what a product manager should be doing (but I rarely see that actually work).

Of course, corporate politics means people try to find a way around them.

> There's always that moment when you don't feel like picking "the one at the top".

A few solutions for this that have worked for me:

* Small units of work

* Having a tech-debt backlog broken into short lumps of cleanup, so you can "take a break" with something different

* Pair programming with frequent pair rotation. The next ticket is always taken by the next open pair, but you can work one something different every few hours if you need.

* trade tasks with a colleague

* sighing, saying, "well, this is my job," and picking the top thing anyhow

To tackle this, I highly recommend the percentile technique from MIT paper, "A Structured Approach to Strategic Decisions". [1]

If you are judging any dimension, say priority, then assigning percentile rating to a task (i.e where does this given task stand relative to all the others) can be quite helpful to overcome the "SuperEvenMoreImportantEmergencyBugfix" cases. This is what the article is also suggesting.

And if you end up assigning 90% percentile to more than 50% of the tasks, you know your judgement is wrong, and it can be corrected accordingly. And it can also be standardized much better across the organization. Everyone can now judge their own judgements.

Rating on multiple dimensions with low correlations important for your company, say signup rate, retention, security, etc. and adding them up is a good way to not miss something important. It's not important to assign weights. Equal weights is fine [2]

I'm finding this technique quite useful in deciding what to work on next with fewer doubts about their priority. I failed to make Trello work for this and use a spreadsheet.

[1] A Structured Approach to Strategic Decisions - https://omegaleadership.com/media/Structured_Approach_to_Str...

[2] The robust beauty of improper linear models in decision making. - https://pdfs.semanticscholar.org/8793/408a67fd4c32bd7b5483d3...

I had to read up on the "means of production" because I had no idea previously that it often refers to the capital (both social and financial) used to produce goods. It's interesting to me that Engels says (in essence) that a worker lacks the means of production and is therefore forced to sell their labour.

But, it occurs to me that this has always been a seller's market. I have, in my naive youth, thought, "What are they going to do, fire me?" Because they might, but it's not like I couldn't another job -- probably even higher paying! What exactly is the "means of production"? Is it really the capital that pays the salary of the programmer, or... is it the will of the programmer to actually write the code? By and large, the programmer is very difficult to replace. If you take note of the incredible number of programmers that are an absolute PITA (I mean, I'm sorry but we are and ornery bunch!), how on earth do they get jobs if the capitalists are not completely desperate. In fact, the big companies even lobby the government to allow them to ship programmers in in large quantities!

So can you not finish and deploy it? I wonder... What could possibly happen?

Small print: Not responsible for loss of livelihood, and social shame that results thereby.

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.

> 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.

Jira supports both. The thing you're describing is called Rank and is used on every board and backlog. Our team uses Rank almost exclusively. The bigger thing to understand here is that different people use different "labeling systems". If you ignore software dev and think about note taking, there are a bunch of different systems. Some work better for one group of people, others work better for another group. I think Jira has had a lot of success because it doesn't force people into one system. The downside is that people often configure it to use 3 different systems at the same time and they vary team to team and this causes a lot of strife and confusion.

This is the most logical, sensible comment in the thread. Jira is the most flexible system for workflow management in existence. The fact that it is extensible is "a feature, not a bug."

I don't see really see anyone stating obvious truths about bad developers & software engineers (as shocking as it may be to read on HN that there are, in fact, objectively bad developers & software engineers with high-paying jobs at companies whose names you know.)

- they are more interested in making a new thing instead of fixing a broken thing they released

- they often can't remember how they built the last new thing

- that's because they aren't interested in building & documenting a fully working thing with test code from the start

- they aren't interested in data structures or architecture built to be easily maintained or in making scale part of their designs

- they despise being told to fix bugs because it is much easier to write code than it is to read it

I believe some organizations implement Jira thinking it is going to solve their cultural problems. This is magical thinking.

I am so tired of hearing about how terrible Jira is from developers.

It's usually the case that where Jira isn't working it has to do with the way it's configured (e.g., giving too many people access to set priority, setting too many priorities, setting too many components, using components in illogical ways, no one actively managing & grooming queues...)

To implement Jira successfully probably requires more work & effort to get it right than to not use it at all. The point of it is not to eliminate the work of issue tracking. It is to organize the workflow management of moving incredibly complex information from one person to the next. It's pretty great at this if you know how to use it.

I completely agree and I hope I explicitly mentioned it in the article: it's not Jira, it's about how people/organizations often think about the problem.

I like the analogy. I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements. Either the requirement wasn't specified well or a change of circumstances requires it to work differently. In either case, it's a request for modification not a bug. Your analogy should help me explain the difference.

> I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements

Oh no.... You are wasting yours and theirs time. This is such a developer thing to do.

Please see my comment to allanniehuis.

The user doesn't care whether the bug is in the requirements or if it's in the code. They just know that it's not working for them, and want it changed.

Arguing that it's not a bug seems like saying 'not my problem' to everyone else. I expect different companies have different cultures around assigning blame that might make saying 'not my fault' important, but I'm pretty sure that customers/users don't care one bit about that.

Whether it's a bug or a modification to requirements I'm still the one who works on it. So "not my problem" doesn't exist in my situation. The distinction matters very much when it comes to prioritizing my work. I'm 100% time on projects and jump from one to the next with no pause between. I'm also the only developer who supports the apps I built. Bugs usually jump to the top of the queue. Management puts a lower priority on requests. In order to not hurt my current "customer", I need to make sure past ones don't try gaming the system by declaring bugs when they're not.

It is very common for companies to forget how to properly prioritize between bugs and features. Trying to reinforce this by trying to teach them how to correctly (according to person on internet) classify bugs or features still sounds like a complete a waste of time.

there's a -- critical -- feedback loop problem that you're ignoring. sure, you might work on it with the same priority regardless of characterization. but if it's properly classified as an error in specification, that is extremely valuable information for process improvement.

> but if it's properly classified as an error in specification, that is extremely valuable information for process improvement.

For a few companies, sure. The chance that he's working on one of those is zero (based on what he has written so far).

Right, to the customer it doesn't matter (just like to the developer it doesn't need to matter either - it just means the work needs to be performed).

However, it matters greatly to other observers - if one person or team is highly out of the norm for rate of bugs, it might be indicative of other problems that need to be worked on (lack of testing, peer review, tasks being assigned beyond the working abilities etc.).

Just like the restaurant analogy - the expectation is that bugs shouldn't be happening to begin with, and when they do, it should be "our fault" to remedy them.

Don't confuse the waiter with the customer.

If the waiter gets the request wrong from the customer, it's still a bug. Even if the kitchen does exactly what was in the waiter request.

It's a team effort.

Please see my comment to allannienhuis.

Yup - from a implementation perspective, bug vs feature is a artificial designation.

Where I think it _does_ matter, is when a business wants to track metrics like "# of bugs over time" or "# of bugs per feature".

My team recently got a lot of heat about "a rising number of bugs", and the insinuation was that our code quality was poor. Turns out, > 75% of the "bugs" reported were mis-labeled feature requests or lack of knowledge about how a particular feature was designed to work.

One way the distinction gets used where I work is to have custom / required fields keyed on the ticket type.

Oh, you want to make a bug ticket in my project? In that case, required fields include "steps to reproduce", "expected result", and "actual result". You want to make a feature ticket in my project? In that case, required fields include "rationale" and "acceptance criteria".

Earlier this year, I reported a bug in Firefox. In my report, I included steps to reproduce the issue, the expected result and the actual result (because I've been on the other side). There were no back-and-forth messages to clarify the issue, and it was fixed in a short amount of time (well, short for a project of that size).

Whoever is giving your team heat about bug metrics needs to read about Goodhart's Law.

There's so many ways to influence number of bugs that it's pointless to measure anything that way. For example, do you make a single bug that lists 15 typos spread around, or 15 bugs (because after all, each typo is a different word and in a different part of the app). Do you accept vague but obviously real bugs while you try to collect enough info over time, or immediately close them as "cannot reproduce"? Is that a bug, or really a feature request?

I do agree completely on "failed promise" and this is actually why I think the bug vs feature is flawed. I think "failed promise" is a great ticket type though ;)

There are obvious cases where I have nothing against what you say. But to use the analogies, "I thought the food would take differently and I don't like this one" is the more common type and it's the one that's murky to resolve.

The point here is that regardless of the reason, you want to tend to "customer is not happy" case.

> They should be a unique set of priorities, with only one single ticket occupying #1 priority, another slightly less one in slot #2 etc.

I've heard the ability to drag & drop tasks around in an ordered list (i.e. a task only has priority relative to others, i.e. it's position in the list) as "ordinal priority".

But you have to acknowledge some features are bugs.

For example, if you have a word processor, having a running word count sounds like a feature.

To a developer it seems frivolous, like having a LOC counter.

But to people who write professionally word count might be the most critical metric of all (like a progress bar for "article is done")

just saying... failed promises

I don't know that I've ever seen a feature that wasn't some sort of "failed promise". The feature sometimes hits and sometimes misses, and is usually somewhere in between. This idea that a defect is a failure of a feature is probably more to do with the inability to predict the future. Sure there are defects like you tried to read from /dev/null, but more realistically the "defects" you see today are more about the inability to predict exactly how a feature is going to be used.

I love the restaurant analogy - it has great resonance especially if you consider cost of making it right.

If I order a Lasagne and get spaghetti meatballs, i think that's a big and i expect to be fixed.

If I order Lasagne and get Beef Lasagne when Inamna vegetarian then I still think it's a big, but the failure is not immediately in the kitchen - why did the waiter not check, if I am wearing dungarees and a a Tee Shirt saying "Die all meat eaters" should that be a clue?

And what about the kitchen response - we all like the restaurant that apologises and comps the food for free. But we would be a bit surprised if we were told the Beef Lasagane was not going to be refunded and we had to pay again to get the veggie one.

But all those models exist in software.

As a developer, I generally find having a distinction between bugs and features useful.

If I'm going to do a big refactoring of some component, I find it useful to look for related open bugs (even if they're low severity) because sometimes it's low or zero extra effort to fix them at the same time. This only works if you have good quality tickets though (proper tags, alias words, etc), which is a whole different topic.

I think it also reduces cognitive load while looking at tickets to have them categorized that way too. Of nothing else being visually distinct (via icon or something) just makes it easier to process.

Above all though, it's important not to argue about bug vs feature. Ideally any bug can link to the feature ticket that isn't working, but either way it's more important to make things better for the customer, so if that means considering a what is really a feature request a "bug" because it'll cause a big argument otherwise, then do that.

I find it useful to differentiate bug from feature because they have a very different information set associated with them. Bugs need to provide description, steps to reproduce, expectation, observation, workaround and are require a write up as part of their completion (root cause). Features, on the other hand, need only a requirements list.

> 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.

Agreed. Github's Stale Bot is the most infuriating, aggravating and insulting bot in widespread use. Every time I encounter it, I reevaluate whether or not I even want to contribute to the project.

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.

I do completely agree. In fact, when people asked me for JIRA, I've always said I am happy to do it since it's a software designed for me, the CTO.

Yet I refuse to do it to them, the ICs.

There may be a similar legibility point about severity levels. Some boss somewhere has to put the set of tasks in priority order for the development team, and once it's in that order, severity levels are useless for the developers. But they might be useful as a way for the person submitting the issue to communicate something to the boss who does the ordering.

Say there's a billing system. One of the accounts receivable clerks notices that due dates aren't properly adjusted for public holidays. As a developer, do you know how big a deal that is? Probably not. Doesn't sound like a big deal. But maybe it means we're imposing penalty charges on customers where we shouldn't be, and that's a huge legal and reputational risk. Or maybe it really isn't a big deal! The boss will need to have a conversation with the clerk to learn all this, but maybe having a severity field is an ice-breaker for that conversation.

Why not have the clerk assign the severity? Why can't the programmer and clerk discuss the problem themselves if there is uncertainty?

The only problems in your scenario arise from the introduction of a boss as go-between.

I am proposing that the clerk should assign the severity.

You could have the programmers do the prioritisation, if they had the business understanding to do that. In that case, they're also the boss. The severity assigned by the clerk could still be a useful starting point.

> 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.

I no longer believe a single tool is good for both a team tracking & communicating amongst themselves about the work they're doing, and communicating the same to and among management. Trying to make them both the same thing is a great way to come up with something that's terrible for one or the other of those uses (usually the former).

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.

Kanban is effectively this.

It works to an extent, but then someone somewhere usually has an abstracted concept of priority, otherwise you end up with priority as per the "highest paid person's opinion".

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.

I disagree. Who is sorting those tickets? Are they sorted arbitrarily or were the technicals considered? Is the ticket at the top feasible given the current state of the codebase/product?

In theory this would work, but it has the pre-requisite that whomever is managing tickets understands technology - which, in my 10 years in the field, has been quite rare.

In my experience, the final sorting needs to be done by a collaboration between ticket manager and someone-who-understands-technology anyway. If the ticket manager doesn't have a clue, they can't make judgement calls necessary as for nontrivial software, it can be hard to say if this is one day or one year of work.

And that affects prioritization a lot.

That would be me. My job is to clarify requirements, gather assets and prepare tasks so that tickets spend less time in progress.

This involves adding a triage column before the todo column. This column is for tickets that are necessary, but not prioritised or ready to work on.

They are sorted according to the project roadmap, usually by a person who understands business requirements, and a person who understands reality.

In my experience, it's usually done in a weekly meeting that involves a small subset of the team. We don't need to estimate tasks. We only need to know their logical order (dependencies) and priority (requirements). We don't need the whole team present for that.

If the requirements or reality change during the week, there is no cost to reordering the todo column. It doesn't change how much gets done, just in which order it gets done.

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.

Another reason to include those fields is that reported bugs are often a case of misaligned expectations between those designing, implementing and testing a feature.

If you're forced to describe what happened and what you expected to happen it makes it very clear when those expectations do not align with those of the people designing or implementing it.

Thanks, this made me think. My first knee-jerk reaction was something about things and implicitness, but after some consideration:

* I am not sure "who reported the issue" is actually important, but rather "who is the contact person to get more information about this issue" and "who should be informed when this is done for verification", where "verification" means "satisfies expectations now" (as opposed to QA meaning of the word)

* Reported happening/expectation is a good point for any expectation mismatch report. I am not sure it should be there for all issues though as I find it can decrease clarity in the same way artificially requiring the "As X, I need to do Y in order to achieve Z" does

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/

"Downtime" as a consequence of an issue is 'severity', not 'priority'. But yes there needs to be a clear and consistent definition of what the different levels of severity mean. This is usually the case because people will quickly notice that it quickly gets messy if everyone makes up their own.

But, as I mention in another comment, severity does not directly map to priority. Something like severity x frequency (classic measurement of risk) is already getting close, but ultimately it is often a judgement call based on other business considerations as well.

I think you misunderstood his point. He is saying that in his system severity == priority. His article he linked lists out explicitly his buckets.

Within a given severity I think its then a judgement call of a product owner to rack-and-stack the issues in priority order, exactly how it would be done for traditional 'P1' - 'P5' grading.

I must confess I've never really understood the need for "severity" in a task tracking system.

As far as I can see, consumers of tickets need to know what order to do stuff in, and producers and organizers and curators of tickets need to set what order things should be done in. That's "priority" or "urgency".

I do understand in a theoretical sense that "Prod system is down" might not always be the absolute highest priority thing to work on. If a particular issue causes a downtime of 1 second every 10 years, it's still downtime, but might not be the most urgent thing to work on.

But that's a theoretical example. In my 20 years of software development and managing projects, if the Prod system is down, it's an emergency, and that's what you need to be working on. So "Prod is down" is a useful priority/urgency. At least that's been my experience so far...

What am I missing? Are there times when priority and severity are useful as two separate fields?

Priority vs severity is an all time classic.

"Severity" is a measure of how serious the impact of a defect is (Using the term "impact" instead of "severity" can make things clearer). It does not say anything about the priority that should be assigned to fixing it, though it is obviously often correlated.

Severity is an absolute metric, priority is a relative metric.

In general the person who creates a defect ticket sets its severity based on what has been observed. The priority is set later by project management.

> If a particular issue causes a downtime of 1 second every 10 years, it's still downtime, but might not be the most urgent thing to work on.

Exactly. There may be a severe issue but because it happens so rarely it is probably not urgent to fix and thus may be assigned a low priority.

Of course if the issue "prod is down" is both severe and urgent to solve. But after investigation you may find the root cause and determine that it is costly to resolve while occurring only very rarely and thus that root cause issue may be low priority though it is still high severity.

The difference really is useful in practice where the effort and cost of solving issues may not be trivial (large systems and systems involving hardware for example). I have seem severe bugs that were tracked down to ASICs deployed in the field, so very expensive to fix, and for which the fix was deferred to the next product version because it was determined that the issue was rare enough that customers could live with it until then.

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...

The main problem I had with them is inability to sort them in a list, which is somewhat solvable with GH Projects now.

For most projects, sorting leads to prioritizing, which is an anti-pattern. For those who choose to eschew proper software development practices, it is nice that Projects is its own thing.

I don't think that prioritizing in general is an anti-pattern. You will do things before other things and you need to choose what to do first. The criticism in the article was about bad prioritization. With GH Projects you can have the liberty to queue issues however you may see fit.

The anti-pattern is premeditating priority. It is true that you have to consider all angles and ultimately determine where to start, but once you've done that it makes no difference where an issue lies in a list.

It’s more than that though. Once the list is sorted, the next time you come back to it, the list is still more or less in the right priority. So the work for prioritization becomes easier.

Once you close an issue the code is in a new state and the list deserves revaluation, returning you right back to square one.

That doesn't seem the case in projects I worked with. In my case, there were more features than engineers and some features were more important than others, so the list made sense. Obviously, it's not set in stone. Features can sometimes jump queue, be completely dropped, or more important features can show up. But I don't think I was ever in a position when a broad list of tasks for the quarter didn't make sense.

Features are emergent out of solving the business needs. If you see a business opportunity in toasting bread, it wouldn't make sense to have an outstanding issue that says "Affix fireplace to the bottom of the apparatus". Instead, knowing your business goal, you start to think about how bread should be toasted and when you come to the revelation that an electric coil is the most efficient method to solve your problem, you finish adding it to the product and then revisit what your next business need is in the context of what now exists and what you have learned in the meantime.

Issues only come into play when your understanding is wrong, to serve as a reminder to revisit your assumptions. New features don't fit. If you are spending so much time finding features to develop faster than you can develop them, your human resource allocation is flawed.

It all depends on the business and business model. For instance, I worked in a classroom app. We had a few goals per quarter but let's just see a couple. For instance, one goal at a certain point was to create all these new lesson types. However, some were clearly more important than others (the ones which were used in almost every lesson was more important than one that's used in a couple. For bigger lesson types there may be more than one issue. For instance, being able to select a single option in a multiple choice lesson can be done before the feature to allow multiple selection and things like that.

Another goal that would frequently appear is paying tech debt. Some changes are also more important than other in that track.

All this work has business value and may be part of the BAU of a established business. I think you're describing a business in a very primordial state. Although, even in startups I've created having a list of things we wanted to do was helpful. We saw our competition we wanted to do better, but we also need to catch up. Lots of things are just obvious and not all the work one does is revolutionary. I don't disagree that changes do occur, though.

We use priority tagging, which allows you to group collections of bugs say: "urgent" . But yes it's hard to actually order the priorities... Haven't tried github projects yet

You only need something more complex or heavy than GH issues (if even that complex) if you've got someone bugging you for burndown charts and metrics and shit just all the time, or someone in the chain who just loves poking around and dragging shit from here to there ("oh goody I'm going to drag this into 'on ice', best day ever!"). The dragging action I don't bring up accidentally—it's very important, for some reason.

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.

For a pretty crazy take on this, take. A look at BaseCamp’s “Shape Up” philosophy, They do not have a backlog. Period. To them, they work a little slower and expect to give enough time to a task to ensure zero bugs instead but then have cycles of bug-fix focus. Additionally, something I found interesting is that every dev is expected to understand the complete stack, that way any dev can fix any corner. Sure this might not work in a larger company without strong levels of splitting up the product, but It’s an enjoyable thing to look at.

If an issue is getting added to or starred or commented on then its not old.

A bug should identify where it was introduced. If a bug was introduced in version 0.5, then version 0.5 forever has that bug, and so the issues is forever valid in that sense, as a truthful comment about a historic thing. If the current version is 1.2, and it has not been confirmed to have fixed the bug, the view should be taken that the bug still exists in 1.2. Bugs don't just become invalid; if we are justified in calling a bug invalid now, that can only be because it was never valid in the first place.

Suppose that someone tries to check, but the bug doesn't reproduce in 1.2. However, it was never root-caused. All we have is a description of the behavior that was happening in 0.5.

Now what? Do you just close that bug to get the open bug count down?

Probably an "unsolved mysteries" or "cold cases" category would be more appropriate for it rather than lumping it with genuinely closed bugs: those that were traced to a root-cause and confirmed.

In cases when you're sure that the bug was due to some software that was entirely rewritten such that the same bug cannot plausibly be in the rewritten version, or some software that was removed entirely, then there is justification in closing that.

As mentioned, this is true for versioned software, not for continuously deployed SaaS.

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.

Both Jira and Trello allow ordering, how does this differ?

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

The only system that I appreciate is taiga. It's extremely opinionated and quite un-configurable.

What I like about it, is that it enforces workflows (either scrum, kanban or simply one-large-backlog) The Way They Were meant. So it solves a lot of bikeshedding and solves me & my team from trying to invent "something that works for us".

The idea proposed by OP works quite well there too, with kanban. Just pick the card at top, and never have more than one card per working person in "active" at any time.

Oh cool, didn't knew about it and it looks like it may be the sweet spot.

A quick web search gives me taiga.io, taiga.pm.

What's the diff if any?

I did not know about taiga.pm. I use the hosted version at taiga.io.

But, since Taiga is FLOSS[1], anyone can host it and/or build a business around it, which -I suspect- is what taiga.pm does.

[1] https://github.com/taigaio

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!

True. I think one of the issues is slapping an issue tracking system on a bunch of different problems.

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.

Um yeah. I mean, I appreciate your ideals. But back down here in the real world, part of that "project plan" is the part about taking a bite off the elephant. You've got to start somewhere. Defining and tracking the progress you've made eating the elephant allows you to know when you've fully consumed it.

And remember, most (all?) software projects are not defined in a singularity. They evolve. As users use the product, the understanding of what you built changes. There is no ability to define a project of any significant size in a box the first time. We aren't pulling rabbits from a hat.

> Defining and tracking the progress you've made eating the elephant allows you to know when you've fully consumed it.

You can also simply keep track by keeping tabs on the work you are doing, which also leads to a better product as you're familiar with what the product does rather than simply knowing that X, Y, and Z issues are closed.

Non-technical stakeholders will not be able to follow it that way, having their focus on other important parts of the business, but that's why you have project managers who can follow what the technical side is doing and provide the necessary non-technical communication to them.

Ultimately, you're both right. There is just some conflation going on. What is useful for some segments of an organization does not make it useful for everyone.

> 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.

I do agree it can totally suck to be on the receiving side.

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.

That's what the author is saying though. The classification of "bug vs. feature" is irrelevant to the user, and trying to convince someone to call it something other than a bug to make the developer feel better is missing the point. What matters is something isn't working for the user, and should be made to work.

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.

Not to mention .. their job is the only one inside the engineering department that doesnt expect them to build/run/test the code hands-on.

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.

I'd say quite the opposite. What you say is one of the myriad of considerations that should go into prioritization by the team, yet is super hard to capture by any hard attribute as I believe the "positive/negative mental health effect" is way more complicated than "bug/feature", yet known by the team.

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.

This analytical approach is exactly what I disagree with.

> A good practice is to fix defects before adding new features, as far as possible

This is the approach I describe as "bug is a proxy for priority", where you are essentially saying it's "highest". It is a good approach in theory, but just ignores business realities.

It also means people will try to disguise feature requests as bugs in order to get a priority.

> Assigning a priority makes sense because it helps setting the ticket's position in a queue

Except if it's numerical, then over time, you can safely ignore everything that's not P1 and you have few dozens/hundreds of unprioritized tickets.

> Severity is not the same as priority.

I know. Why is it important to make the distinction though?

> 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.

Agreed.

> 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.

Well, if dev is a factory worker turning inbound tickets into outbound features, yeah, cool, this works.

I am yet to see this in practice. Team (or at least team lead) is taking active role in the managing cycle and this is exactly what renders a lot of your points at least duplicit.

(But you have a lot of good points about assumptions about team organization that should be mentioned)

It is a fantastic article Almad, thanks!

About the only thing I might add is dependencies. But even that is mostly value for management reporting and time estimation. It doesn't help the workers do their jobs that much.

Thanks!

Yeah, this is something worth a separate article (this one felt long already): ticket systems as reporting tools.

This analytical approach is the reality of managing tickets taking technical and business realities into account.

A bug is not a proxy for priority. As said it is a parameter that helps defining a priority and, in fine, the position in the TODO list. Whether priority is "high", or P1, or whatever is exactly the same. Usually there no need for too many levels because, as you suggest, it mostly boils down to "now", "afterwards", "whenever", and that changes over time (hence Agile ideas).

BTW, I have never seen someone disguising a feature request as a bug. That is totally unrealistic not least because obviously this is continuously scrutinised and someone doing that would be called out and ultimately fired for shear incompetence (or worse) and because features go through a definition process, it's not someone who suddenly dreams one up and sneakily hide it in a bug report to have it implemented without anyone noticing (what?!)

The distinction between severity and priority is important. Severity is assigned by the person who reports a defect. It is a measure of how serious the impact of the defect is, as said. Priority cannot be set at that point, as it is a judgement made later based on further considerations.

Devs really are as I described in teams that have matured and are organised (but maybe not in "messier" startups). A team lead is not a dev, 'lead' implies a managerial aspect.

Lastly, of course you need to keep track of the number of defects (which can be from customers feedback and production metrics) and of their severity. This is basic QA, you have to know if you are effectively doing a good job in order to improve both your internal processes and the quality of your product.

For example, if I start to see too many critical defects on a component/team I know we have a problem there. If I start to see too many critical defects found after the product has shipped I know we have a big problem.

I'd agree with you if I would be only seeing the teams through my management reports and not from the trenches.

I am envious of the environment where you never saw somebody trying to bug feature request as a bug. I do think in a lot of cases, it's a judgement call...or a habit where problems perceived as bugs by customers are swung under the carpet as features as bug is only defined as "deviation from requirements".

Fair on distinction of severity by customer vs priority by team, although I am used to make a distinction between support ticket by customer and issue in engineering team's queue.

Lead implies either managerial or technological leadership and especially in mature organisations, I've seen both.

My experience with management by bug statistics is...very inconsistent as it motivates people to game the system...and boy I've seen that a lot. I do agree trend knowledge helps, but I am not sure it's worth the side-effects and work.

Of course, a flavor of this depends on context (and scale). It is very different if you have a single-instance SaaS, distributed system or images shipped to air-gapped systems.

> I am envious of the environment where you never saw somebody trying to bug feature request as a bug.

Really, I have never seen that in 20 years.

Of course that is different from another team or the test team raising a bug because they expected something that was not in the spec. Then you tell them that it's not because it does not behave the way they want that it is a bug. But, yes, a defect (more general term than bug) is any deviation from requirements.

Direct input from customers is different as well. Unless there is a contractual impact, if a customer is adamant something is a bug when it technically isn't then there is no point arguing. You can treat the request however you want internally.

> It also means people will try to disguise feature requests as bugs in order to get a priority.

If my car breaks and cannot start, that's a bug. If I want to add a radio to my car, that is an extra feature. The difference exists, and it is important. You are saying this difference should be ignored because someone may try to pass the desire for a radio as a broken car. At that point, you could just ignore any issue because it may be a lie.

And the reason to categorize is not only to prioritize. For example, we have these rules: bugs require of a test case, and the test must pass to consider close the bug. On the other hand, new features are implemented first in a different tree, and the new feature needs to be documented (also in the tutorial). Moreover, we may have meetings to decide if we add a feature or not (for example, different new features may not work well together or may require extensive refactoring that we do not want to do), while a bug must be fixed.

In your workflow, this distinction may not be important. That's perfectly possible. But, in my opinion, claiming that "we collectively shouldn't care" is going to far (unless "we collectively" means something more specific than it looks to me).

> 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.

I would love if you could expand on that. Do you really need it? Is this more important than production metrics or customer feedback?

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.

"Season to taste" I totally agree with, no way to capture the whole world in a signel post ;)

> 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.

I do agree it's about routing. My problem with components is alignment with teams and their stability over time and survival of existing tickets across those changes, which is why I think different routing mechanisms are better. But yeah, if it works...

> Same goes for priority - sometimes you do need it. That zero-day you're fixing is a "drop everything else" bug.

I call those "an incident" and in every environment I've been at, everybody knew which one it is very well without any labels ;)

If you can share more about different routing mechanisms, I'd love to hear it. It's not that components are making me happy, per se ;)

As for the priority label - it makes sense if there's either a huge bug load (cf. bug hygiene ;) or in environments where you have automated workflows. I.e filing a bug with P0 alerts the responsible engineer, starts a log document for the inevitable post mortem, lets production know, whatever you need to do for P0s.

Not all fields in the database are for humans :)

I have occasionally thought it'd be nice if we ditched a lot of UI & status fields, and the IC view in the bug database is just "what is the most important thing for me to work on right now". One issue. Only comment history, no other fields. You still need the rest for reporting, analysis, workflows, but as IC, that's what you care about.

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

A bug report does not imply a user is angry or not. Software is shipped with known bugs which often go unfixed. And a lack of features can be just as critical of an impediment for a user. So neither bug nor feature can fully describe the effect that an identified issue has on its overall priority.

An angry phone call doesn't universally change the order of work for all companies. Some projects might rate this event more importantly than other projects. Most angry phone calls are a result of usability problems not strictly feature defects. So there's no direct correlation here between user product sentiment and backlog priorities, unless your company culture adds that correlation.

thanks for this nuances.

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.

Most if not all software is shipped with known defects. So clearly, the fact that a "bug" can be identified doesn't give any weight when describing when it needs to be fixed.

A missing feature can be just as onerous to a user as a defect. Understanding if an issue gets in the way of productivity is all that matters, regardless if it's described as a bug or a feature.

Tracking metrics against bug vs. feature is a surefire way for a system to be gamed. If there are consequences in finding/reporting defects, then all work-items will eventually be labeled as "features". Or if you reward finding bugs, then all work-items will gravitate towards "defects". It's up to you how you want to play this game.

Fair, although, depends on scale again. As they say, at scale, every implementation detail is something customers rely on :)

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?

Hmm, I communicated wrongly then. Because the separate system for issues is for a different team and a different purpose and no, it's definitely not a solution to the problem, but rather a prerequisite for the outlined system to have a chance at working at all.

You described it as a “separate system for handling questions for the development team”.

How do you propose that queue is prioritised and consumed by the development team?

In both companies I've been using that, it was a very simple RT/JIRA-SD-style system: "open a subject/text ticket, clock starts ticking, on call engineer gets a non-wake-up memo and will reply with high priority during work hours" and ticket will get closed ASAP and we do achieve inbox 0 regularly.

Yes, there are obvious issues and it requires two things to work:

1) If you actually have no clue about the product, you are respectfully told to fuck off to normal user support channel 2) If you keep misusing this for user support / slack channel, you get your access revoked.

...which are hard sells in large companies, of course—on the other hand, in BigCo I got success in getting an engineering headcount to accommodate that.

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

It's my full time job, and I agree. However keeping Jira in line with reality helps me catch inconsistencies in requirements and plans.

Working in Jira and (especially) Asana always feels like working on a VNC share of the person in charge's cluttered desktop-covered-in-folders organizational system. Everything's hard to find and I'm afraid to touch anything for fear I'll accidentally drag something somewhere then not be able to find it again to put it back.

Except it's that plus 1.5GB of memory use and a few tens of a % of a processor core.

[EDIT] and I've found that to be true when working for people so good at using the software that they made popular training videos for it, not just morons who don't know how they work.

Sometime I wish that my project was managed in a folder with neatly arranged subfolders all in ASCII text. Specs in the specs-folder. Release lists in the release list folder.

Bugs in the bugs folder, with a text file for "reported", "active" and "fixed" bugs sorted by release version folders.

I honestly would want to try it. Files and folders are the abstraction that was supposed to replace physical folders with files, but in practice files stored in computers/network/mail are just a bunch of papers randomly put everywhere. How about using folders as they were supposed to ...

> 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.

Would people otherwise be aware that Steve has an order of magnitude more bugs than anyone else?

I actually never new about bugs being assigned to people as opposed to products, interesting to know.

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.

These fields aren't required for a good ticket system to work. They might be useful in terms of post-mortems, generating changelogs, etc. But fundamentally, the "version" that a issue was resolved in is not a requirement of the ticket tracking system. Some continuously deployed software doesn't really ever have a version number at all.

>>> 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..

They create them and they go first in the queue. If there is more than one, they have to decide which is first.

If there are conflicts then it's up to the managers to fight it out.

That's not what I'm talking about: when a software is late there is a 'panic phase' by the managers where they forbid the creation of 'high severity' bug tickets. So if there is no more bug tickets what will happen when the managers are in 'panic mode'? Something to think about before removing bug tickets.

Okay, hmm. It seems like if you already have a lot of high-priority work then logically, most new bugs will go after them in the queue.

And if you're running out of time, that would amount to the same thing, since you'll never get to it.

Also, so long as you have enough work queued up for a few weeks, there is not really much point to stack-ranking the remaining queue items anyway. Everything else is "lower priority".

If you mean how to prevent them, well, no bugs so no way to create them.

If you mean how they handle them, there is an incident procedure for that. If it's not really an incident but, well, I need this next week for Gartner Magic Quadrant...I have phone numbers of managers in my reporting chain.

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.

Happy to, glad you like it

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?

It's your browser's default styling. Only CSS I see is:

  article {hyphens: auto;}

There is no CSS on the page. I have a feeling your comment was facetious though, hinting at the amount of bloat (e.g. Jekyll theme) we need today to do the simplest things.

There Are No Margins, Just TODOs

As the frontpage says, intentionally deferred :P

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

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

One of the reasons I am delaying design is getting deeper into accessibility and readability research. And I have decided to write some content first ;)

This idea is very clever:

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

These can lead to discussions similar to "it's a feature, not a bug."

Is "Make app work on device X" or "Add cornercase Y" new or upkeep?

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.

Note: Author is Eastern Europian, so #totes

There are no TODOs, just bugs.

You've made the same point as the author. The idea that a "ticket" or "work-item" has any sort of label (defect, feature, todo) or priority (high, low, now) doesn't add value. The label you give a work-item is meaningless. The value comes strictly from the change being applied.

You caught me because I didn't read the article. I was just thinking of the old duality between bugs and features. An unimplemented feature is just the bug "the software doesn't have this feature yet", and a bug fix is implementing the feature that "the software should do this correct thing instead of that buggy thing". Since this insight is decades old, maybe I should switch to saying the article contains nothing new?

> 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.

> 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.

Agreed. My point was more about that there has to be a single person responsible for making sure there are no leftovers.

> But the development team itself can do that, no problem.

Yup. To the domain point, I do think that collaboration on that boundary is needed.

> It's relevant to estimating velocity (...)

Fair, if you only define velocity as adding features and if you automatically prioritize bugs.

> We must recognise this as simply being an expression of the author's deletionist aesthetic preference, not a fact about the world.

I think this doesn't hold over long term. It is true as long as you do have an idea what's in the rest of the pile. But the moment you change the person responsible for managing the tickets and suddenly they have thousand tickets to go through and orient themselves in, it matters. And if they don't go through all of them, they don't actually do the prioritization against each other.

It's cool! I agree ;)

Hey,me too!

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

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

Reply on news.ycombinator.com