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 ;)
There Are No Bugs, Just TODOs
191–200 of 204 posts
Re: There Are No Bugs, Just TODOs
#192Something 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.…
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.
Re: There Are No Bugs, Just TODOs
#193Earlier quoted context omitted.
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.
Re: There Are No Bugs, Just TODOs
#194With 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.…
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.
Re: There Are No Bugs, Just TODOs
#195Earlier quoted context omitted.
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…
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…
Re: There Are No Bugs, Just TODOs
#196Earlier quoted context omitted.
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 a…
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 pri…
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.
Re: There Are No Bugs, Just TODOs
#197Earlier quoted context omitted.
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 a…
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).
Re: There Are No Bugs, Just TODOs
#198Earlier quoted context omitted.
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.
Re: There Are No Bugs, Just TODOs
#199Super 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.
Re: There Are No Bugs, Just TODOs
#200Earlier quoted context omitted.
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 rus…
> 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 a…
> [...] 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.