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

31–40 of 356 posts

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

#31

Post by gyomu »

triyambakam wrote: post #27
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. Now I find that odd.

I don’t. I worked on firmware stuff where unexplainable behavior occurs; digging around the code, you start to feel like it’s going to take some serious work to even start to comprehend the root cause; and suddenly you find the one line of code that sets the wrong byte somewhere as a side effect, and what you thought would fill up your week ended up taking 2 hours.

And sometimes, the exact opposite happens.

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

#32

Post by ChrisMarshallNY »

lapcat wrote: post #25
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. This is explained later in the post. The 2 day hard limit is applied not to the estimate but rather to the actual work: "If something is ballooning, cut your losses. File a proper bug, move it to the backlog, pick something else."

Most of the work in finding/fixing bugs is reproducing them reliably enough to determine the root cause.

Once I find a bug, the fix is often negligible.

But I can get into a rabbithole, tracking down the root cause. I don’t know if I’ve ever spent more than a day, trying to pin down a bug, but I have walked away from rabbitholes, a couple of times. I hate doing that. Leaves an unscratchable itch.

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

#33

Post by PaulKeeble »

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…

Sometimes you find the cause of the bug in 5 minutes because its precisely where you thought it was, sometimes its not there and you end up writing some extra logging to hopefully expose its cause in production after the next release because you can't reproduce as its transient. I don't know how to predict how long a bug will take to reproduce and track down and only once its understood do we know how long it takes to fix.

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

#35

Post by jaredsohn »

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

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.

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

#36

Post by BurningFrog »

Celeo wrote: post #19
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!!

Depending on the size of the team/org/company, working on anything other than the next feature is a hard sell to PM/PO/PgM/management.

That's what I hear.

I've had some mix of luck and skill in finding these jobs. Working with people you've worked with before helps with knowing what you're in for.

I also don't really ask anyone, I just fix any bugs I find. That may not work in all organizations :)

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

#38

Post by wahnfrieden »

chii wrote: post #20
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…

I find most bugs take less time to fix than it takes time to verify and reproduce.

LLMs have helped me here the most. Adding copious detailed logging across the app on demand, then inspecting the logs to figure out the bug and even how to reproduce it.

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

#39

Post by ben0x539 »

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

In your experience, is there a lot of contention over whether a given issue counts as a bug fix or a feature/improvement? In the article, some of the examples were saving people a few clicks in a frequent process, or updating documentation. Naively, I expect that in an environment where bug fixes get infinite priority, those wouldn't count as bugs, so they would potentially stick around forever too.

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

#40

Post by thundergolfer »

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

This is the 'Zero Defects'[1] mode of development. A Microsoft department adopted it in 1989 after their product quality dropped. (Balmer is cc'd on the memo.)

1. https://sriramk.com/memos/zerodef.pdf

Post reply on HN