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

91–100 of 356 posts

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

#91

Post by OhMeadhbh »

auguzanellato wrote: post #72
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.

What kind of LA did you use to de bug an Intel core?

The hardware team had some semi-custom thing from intel that spat out (no surprise) gigabytes of trace data per second. I remember much of the pain was in constructing a lab where we could drive a test system at reasonable loads to get the buggy behavior to emerge. It was intermittent so it took use a couple weeks to come up with theories, another couple days for testing and a week of analysis before we came up triggers that allowed us to capture the data that showed the bug. it was a bit of a production.

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

#92

Post by baq »

siliconc0w wrote: post #59

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.

ROI is in reduced backlog, reduced duplicate reports and most importantly mitigation of risk of phase transition between good enough and crap. This transition is not linear, it’s a step function when the amount of individually small and mildly annoying at worst issues is big enough to make the experience of using the whole product frustrating. I’m sure you can think of very popular examples of such software.

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

#93

Post by baq »

Barbing wrote: post #88
foxygen wrote: post #83

Earlier quoted context omitted.

Oh boy, I’d trade one(or easily 2/3) major MacOs version for a year worth of bug fixes in a heartbeat.

You got it per Gurman: >For iOS 27 and next year’s other major operating system updates — including macOS 27 — the company is focused on improving the software’s quality and underlying performance. -via Bloomberg today

I’ll believe it when I see it, but holy quality Batman I want to believe.

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

#94

Post by mavamaarten »

jaredklewis wrote: post #79
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!!

Where have you worked where this was practiced if you don’t mind sharing? I’ve seen very close to bug free backends (more early on in development). But every frontend code base ever just always seems to have a long list of low impact bugs. Weird devices, a11y things, unanticipated screen widths, weird iOS safari quirks and so on. Also I feel like if this was official policy, many managers would then just start classi…

I'm not going to share my employer, but this is exactly how we operate. Bugs first, they show up on the Jira board at the top of the list. If managers would abuse that (they don't), we'd just convert them to stories, lol.

I do agree that it's rare, this is my first workplace where they actually work like that.

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

#95

Post by Lionga »

ChrisMarshallNY wrote: post #70
wahnfrieden wrote: post #38

Earlier quoted context omitted.

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.

Yes. I often just copy the whole core dump, and feed it into the prompt.

And this kids is how one bug got fixed and two more were created

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

#96

Post by Lionga »

Barbing wrote: post #88
foxygen wrote: post #83

Earlier quoted context omitted.

Oh boy, I’d trade one(or easily 2/3) major MacOs version for a year worth of bug fixes in a heartbeat.

You got it per Gurman: >For iOS 27 and next year’s other major operating system updates — including macOS 27 — the company is focused on improving the software’s quality and underlying performance. -via Bloomberg today

how will the poor engineers get promotions if they can not write "Launch feature X" (broken, half baked) on their promotion requests? Nobody ever got promoted for fixing bugs or keeping software useable.

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

#97

Post by amoss »

OhMeadhbh wrote: post #51
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.

When you work on compilers, all bugs are compiler bugs.

(apart from the ones in the firmware, and the hardware glitches...)

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

#98

Post by PeterStuer »

Confused about the meaning of "bug" used in this artcle. It seems to be more about feature requests, nice to haves and polish rather than actual errors in edge cases.

Also explains the casual mention of "estimation" on fixes. A real bug fix is even more hard to estimate than already brittle feature estimates.

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

#99

Post by boxed »

I did this with my entire employment at a company I worked with. Or rather, I should say I made it a point to ignore the roadmap and do what was right for the company by optimizing for value for customers and the team.

Fixit weeks is a band aid, and we also tried it. The real fix is being a good boss and trusting your coworkers to do their jobs.

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

#100

Post by mat0 »

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…

you cannot know. that’s why the post elaborates saying (paraphrasing) “if you realize it’s taking longer, cut your losses and move on to something else”
Post reply on HN