There Are No Bugs, Just TODOs • Hacker News Board

Re: There Are No Bugs, Just TODOs

#201

Post by aflag » Mon, Jun 08, 2020, 10:02 PM UTC

randomdata wrote: post #198

tomkwong wrote: post #193

Earlier quoted context omitted.

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.

Re: There Are No Bugs, Just TODOs

#202

Post by randomdata » Tue, Jun 09, 2020, 5:05 PM UTC

aflag wrote: post #201

randomdata wrote: post #198

Earlier quoted context omitted.

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.

Re: There Are No Bugs, Just TODOs

#203

Post by berkes » Wed, Jun 10, 2020, 8:31 AM UTC

emmelaich wrote: post #23

berkes wrote: post #5

Earlier quoted context omitted.

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 car…

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

Re: There Are No Bugs, Just TODOs

#204

Post by aflag » Fri, Jun 12, 2020, 10:22 PM UTC

randomdata wrote: post #202

aflag wrote: post #201

Earlier quoted context omitted.

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…

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.