Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We stopped roadmap work for a week and fixed bugs

lalitm.com

Post reply on HN
Print view View original

51–60 of 356 posts

Re: We stopped roadmap work for a week and fixed bugs

#51

Post by OhMeadhbh »

ChrisMarshallNY wrote: post #16

I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…

At Amazon we had a bug that was the result of a compiler bug and the behaviour of intel cores being mis-documented. It was intermittent and related to one core occasionally being allowed to access stale data in the cache. We debugged it with a logic analyzer, the commented nginx source and a copy of the C++ 11 spec.

It took longer than 2 days to fix.

Re: We stopped roadmap work for a week and fixed bugs

#52

Post by supriyo-biswas »

NegativeK wrote: post #47
jaredsohn wrote: post #35

Earlier quoted context omitted.

I'd love to see an actual bug-free codebase. People who state the codebase in bug-free probably just lack awareness. Even stating we 'have only x bugs' is likely not true.

Top commenter's "AFAYK" acronym is covering that. The type that claims they're going to achieve zero known and unknown bugs is also going to be the type to get mad at people for finding bugs.

> The type that claims they're going to achieve zero known and unknown bugs is also going to be the type to get mad at people for finding bugs.

This is usually EMs in my experience.

At my last job, I remember reading a codebase that was recently written by another developer to implement something in another project, and found a thread safety issue. When I brought this up and how we’ll push this fix as part of the next release, he went on a little tirade about how proper processes weren’t being followed, etc. although it was a mistake anyone could have made.

Re: We stopped roadmap work for a week and fixed bugs

#53

Post by riwsky »

So much of the tech debt work scheduling feels like a coordination or cover problem. We’re overdue for a federal “Tech Debt Week” holiday once a year, and just save people all the hand-wringing of how when or how much. If big tech brands can keep affording to celebrate April fools jokes, they can afford to celebrate this.

Re: We stopped roadmap work for a week and fixed bugs

#54

Post by Uehreka »

ChrisMarshallNY wrote: post #16

I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…

> It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done.

In my experience there are two types of low-priority bugs (high-priority bugs just have to be fixed immediately no matter how easy or hard they are).

1. The kind where I facepalm and go “yup, I know exactly what that is”, though sometimes it’s too low of a priority to do it right now, and it ends up sitting on the backlog forever. This is the kind of bug the author wants to sweep for, they can often be wiped out in big batches by temporarily making bug-hunting the priority every once in a while.

2. The kind where I go “Hmm, that’s weird, that really shouldn’t happen.” These can be easy and turn into a facepalm after an hour of searching, or they can turn out to be brain-broiling heisenbugs that eat up tons of time, and it’s difficult to figure out which. If you wipe out a ton of category 1 bugs then trying to sift through this category for easy wins can be a good use of time.

And yeah, sometimes a category 1 bug turns out to be category 2, but that’s pretty unusual. This is definitely an area where the perfect is the enemy of the good, and I find this mental model to be pretty good.

Re: We stopped roadmap work for a week and fixed bugs

#55

Post by OhMeadhbh »

ChrisMarshallNY wrote: post #24
kykat wrote: post #21

Earlier quoted context omitted.

Sometimes, a "bug" can be caused by nasty architecture with intertwined hacks. Particularly on games, where you can easily have event A that triggers B unless C is in X state... What I want to say is that I've seen what happens in a team with a history of quick fixes and inadequate architecture design to support the complex features. In that case, a proper bugfix could create significant rework and QA.

In that case, maybe having bug fixing be a two-step process (identify, then fix), might be sensible.

I do this frequently. But sometimes identifying and/or fixing takes more than 2 days.

But you hit on a point that seems to come up a lot. When a user story takes longer than the alloted points, I encourage my junior engineers to split it into two bugs. Exactly like what you say... One bug (or issue or story) describing what you did to typify the problem and another with a suggestion for what to do to fix it.

There doesn't seem to be a lot of industry best practice about how to manage this, so we just do whatever seems best to communicate to other teams (and to ourselves later in time after we've forgotten about the bug) what happened and why.

Bug fix times are probably a pareto distribution. The overwhelming majority will be identifiable within a fixed time box, but not all. So in addition to saying "no bug should take more than 2 days" I would add "if the bug takes more than 2 days, you really need to tell someone, something's going on." And one of the things I work VERY HARD to create is a sense of psychological safety so devs know they're not going to lose their bonus if they randomly picked a bug that was much more wicked than anyone thought.

Re: We stopped roadmap work for a week and fixed bugs

#56

Post by ls-a »

asdfman123 wrote: post #12
ls-a wrote: post #10

189 bugs in one week. How many employees quit after that?

They said they only pick bugs that take 2 days to fix. Places where you can move fast and actually do things are actually far better places to work for. I mean the ones were you can show up, do 5 hours of really good work, and then slack off/leave a little early.

Nothing takes 2 days to fix. Those are definitely not bugs, like someone else mentioned

Re: We stopped roadmap work for a week and fixed bugs

#57

Post by RHSeeger »

BurningFrog wrote: post #14

This is weird to me... The way I learned the trade, and usually worked, is that bug fixing always comes first! You don't work on new features until the old ones work as they should. This worked well for the teams I was on. Having a (AFAYK) bug free code base is incredibly useful!!

Bugs have priorities associated with them, too. It's reasonable for a new feature to be more important than fixing a lower priority bug. For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it.

Re: We stopped roadmap work for a week and fixed bugs

#58

Post by triyambakam »

ChrisMarshallNY wrote: post #30
triyambakam wrote: post #27

Earlier quoted context omitted.

> It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. Now I find that odd.

Yeah, I’m obviously a terrible programmer. Ya got me.

I just find it so oversimplified that I can't believe you're sincere. Like you have entirely no internal heuristic for even a coarse estimation of a few minutes, hours, or days? I would say you're not being very introspective or are just exaggerating.

Re: We stopped roadmap work for a week and fixed bugs

#59

Post by siliconc0w »

I'm a bit torn on Fix-it weeks. They are nice but many bugs simply aren't worth fixing. Generally, if they were worth fixing - they would have been fixed.

I do appreciate though that certain people, often very good detail oriented engineers, find large backlogs incredibly frustrating so I support fix-it weeks even if there isn't clear business ROI.

Re: We stopped roadmap work for a week and fixed bugs

#60

Post by com2kid »

triyambakam wrote: post #58
ChrisMarshallNY wrote: post #30

Earlier quoted context omitted.

Yeah, I’m obviously a terrible programmer. Ya got me.

I just find it so oversimplified that I can't believe you're sincere. Like you have entirely no internal heuristic for even a coarse estimation of a few minutes, hours, or days? I would say you're not being very introspective or are just exaggerating.

My team once encountered a bug that was due to a supplier misstating the delay timing needed for a memory chip.

The timings we had in place worked, for most chips, but they failed for a small % of chips in the field. The failure was always exactly identical, the same memory address for corrupted, so it looked exactly like an invalid pointer access.

It took multiple engineers months of investigating to finally track down the root cause.

Post reply on HN