There Are No Margins, Just TODOs
As the frontpage says, intentionally deferred :P
There Are No Bugs, Just TODOs
171–180 of 204 posts
Re: There Are No Bugs, Just TODOs
#172Interesting 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…
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.
Re: There Are No Bugs, Just TODOs
#173> 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.…
> 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.
Re: There Are No Bugs, Just TODOs
#174With 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…
"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 ;)
Re: There Are No Bugs, Just TODOs
#175There 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?
Re: There Are No Bugs, Just TODOs
#176There are no "bugs". There are "defects". -- HP, back when they were good.
Re: There Are No Bugs, Just TODOs
#177I 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 int…
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…
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.
Re: There Are No Bugs, Just TODOs
#178From 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.
Re: There Are No Bugs, Just TODOs
#179From 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 invar…
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.
Re: There Are No Bugs, Just TODOs
#180I 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 int…
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.