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

301–310 of 356 posts

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

#301

Post by nemetroid »

ahoka wrote: post #133
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…

Not sure why would you ever need to refactor for fixing a bug?

A nice way to fix bugs is to make the buggy state impossible to represent. In cases where a bug was caused by some fundamental flaw in the original design, a redesign might be the only way to feel reasonably confident about the fix.

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

#302

Post by bottlero_cket »

Aurornis wrote: post #274
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…

All of the buggy software projects I've been employed to work on have had some version of this rule. Usually it's implicit, rather than explicit: Nobody tells you to limit work on bugs to 1-2 days, but if you spend an entire week debugging something difficult and don't accumulate any story points in Jira, a cadre of project manager, program managers, and other manager titles you didn't even know existed will descend…

Lesson learned, just avoid the hard bugs, I don’t think that is feasible for most of us!

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

#303

Post by 1718627440 »

aeternum wrote: post #287
Aurornis wrote: post #274

Earlier quoted context omitted.

All of the buggy software projects I've been employed to work on have had some version of this rule. Usually it's implicit, rather than explicit: Nobody tells you to limit work on bugs to 1-2 days, but if you spend an entire week debugging something difficult and don't accumulate any story points in Jira, a cadre of project manager, program managers, and other manager titles you didn't even know existed will descend…

It's the right lesson because the difficulty of the bug often depends on the dev. For example it might take one dev weeks to figure out that a hang due to a sleep(.001) call within asyncio whereas another can identify it with a glance at the code.

Which is why they get payed different rates.

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

#304

Post by BurningFrog »

IgorPartola wrote: post #286
BurningFrog wrote: post #268

Earlier quoted context omitted.

Two thoughts: - This bug genuinely sounds like low priority. - This organization seems to operate assuming unforeseen problems will never pop up. That is unwise.

Yes exactly. Any non-critical out of current scope bug must be evaluated for whether it should interrupt the current work. Is it a priority? You cannot automate this process by saying “if is_bug: return {priority: IMMEDIATE}” as suggested by the quote about id above, because you will absolutely destroy any velocity. In fact that quote seems to me to be talking about not committing new code with known bugs, not droppi…

Your argument is only true if you have an infinite number of bugs.

If you only have a reasonable number of bugs, and fix them as you find them, it's just how you do work.

It may sound impossible, but I did work like this for two decades, and it worked well for those teams.

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

#305

Post by 1718627440 »

bluGill wrote: post #275
dylan604 wrote: post #261

Earlier quoted context omitted.

we've gotten into adding verbosity levels in logging where each logged event comes with an assigned level that only makes it to the log if it matches the requested log level. there are times when a full verbose output is just too damn much for day-to-day debugging, but is helpful when debugging the one feature. i used to think options like -vvv or -loglevel panic were just someone being funny, but they do work when n…

On smaller projects that works. We have a complex system where individual logs can get the log level changed. Though this turns out too fine grained. I'm moving to every subsystem being controllable, but not the individual logs. I'm still not sure what the right answer is though - it always seems like there are 10,000 lines of unrelated useless logs to wade through before finding the useful one, but anytime I remove…

Use something like syslog, where everything is recorded and you can filter on display by subsystem and loglevel.

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

#306

Post by codingdave »

> Then the week before fixit, each subteam goes through these bugs and sizes them:

I advocate to never size/score bugs. Instead, if your process demands scores, call everything a 2 because over the course of all the bugs, that will be your average. You'll knock out 10 small ones and then get stuck on a big one. Bug-fixing efforts should be more Kanban than Scrum. Prioritize the most important/damaging/whatever ones, do them in order, and keep doing them until they are done or you run out of time.

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

#309

Post by IgorPartola »

BurningFrog wrote: post #304
IgorPartola wrote: post #286

Earlier quoted context omitted.

Yes exactly. Any non-critical out of current scope bug must be evaluated for whether it should interrupt the current work. Is it a priority? You cannot automate this process by saying “if is_bug: return {priority: IMMEDIATE}” as suggested by the quote about id above, because you will absolutely destroy any velocity. In fact that quote seems to me to be talking about not committing new code with known bugs, not droppi…

Your argument is only true if you have an infinite number of bugs. If you only have a reasonable number of bugs, and fix them as you find them, it's just how you do work. It may sound impossible, but I did work like this for two decades, and it worked well for those teams.

No. My argument is valid if you have deadlines and your resources are not infinite. Either you were the only one reporting bugs at which point of course you could fix the as you found them because they were always in your work context or you had no deadlines and could afford to switch context without the inefficiency of it affecting anything.

In most situations you have users who also find bugs and report them when they want, not when you are ready for them.

You can even see that your argument does not apply generally by the fact that bugs exist in software for years. If your way was both more efficient AND more aligned with human nature then everyone would be working like this but clearly almost nobody can afford to drop everything to fix a user’s random low priority bug the minute it is reported.

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

#310

Post by buildbot »

ChrisMarshallNY wrote: post #73
OhMeadhbh wrote: post #51

Earlier quoted context omitted.

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.

I’m old enough to have used ICEs to trace program execution. They were damn cool. I seriously doubt that something like that, exists outside of a TSMC or Intel lab, these days.

They float around on ebay! Software might be an issue.
Post reply on HN