We stopped roadmap work for a week and fixed bugs • Hacker News Board

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

#251

Post by Wololooo » Mon, Nov 24, 2025, 4:39 PM UTC

AdamN wrote: post #208

mentos wrote: post #196

Earlier quoted context omitted.

Reminds me of ids policy of "As soon as you see a bug, you fix it" "...if you don't fix your bugs your new code will be built on buggy code and ensure an unstable foundation and if you check in buggy code someone else is going to be writing code based on your bad code and well you know you can imagine how wasteful that's going to be" 16:22 of "The Early Days of id Software: Programming Principles" by John Romero (Str…

Yeah, Joel Spolsky is adamant about this with the "Bugs First" approach and he claims most of the delays and garbage that Microsoft released during the early years of his career were centered on that one rule being violated.

The problem is even if you make a note to fix it later, one you never get back to it and two this drives decisions for things around it, until it breaks...

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

#252

Post by com2kid » Mon, Nov 24, 2025, 4:54 PM UTC

snovv_crash wrote: post #101

com2kid wrote: post #89

Earlier quoted context omitted.

Have you ever fixed random memory corruption in an OS without memory protection? Best case you trap on memory access to an address if your debugger supports it (ours didn't). Worst case you go through every pointer that is known to access nearby memory and go over the code very very carefully. Of course it doesn't have to be a nearby pointer, it can be any pointer anywhere in the code base causing the problem, you ju…

This is why a test suite and mock application running on the host is so important. Tools like valgrind can be user to validate that you won't have any memory errors once you deploy to the platform that doesn't have protections against invalid accesses. It wouldn't have caught your issue in this case. But it would have eliminated a huge part of the search space your embedded engineers had to explore while hunting down…

Custom OS, cross compiling from Windows, using Arm's old C compiler so tools like valgrid weren't available to us.

Since it was embedded, no malloc. Everything being static allocations made the search possible in the first place.

This wasn't the only HW bug we found, ugh.

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

#253

Post by knallfrosch » Mon, Nov 24, 2025, 4:58 PM UTC

It's concerning that noone was able to fix these bugs as an "aside".

With an average of 4 bugs fixed in 5 days and 150 bugs, we can assume 50 bugs with less than one days's effort were just lying around with noone daring to touch them.

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

#254

Post by jamil7 » Mon, Nov 24, 2025, 5:05 PM UTC

pmontra wrote: post #118

About stopping and fixing problems, did anybody have had this kind of experience? 1. Working on Feature A, stopped by management or by the customer because we need Feature B as soon as possible. 2. Working on Feature B, stopped because there is Emergency C in production due to something that you warned the customer about months ago but there was no time to stop, analyze and fix. 3. Deployed a workaround and created i…

Yes, it's a leadership failure and probably time to go, it only gets worse. In my experience. It's a vicious cycle where, as velocity slows, inexperienced leadership gets more and more panicked and starts frantically rearranging projects, features and people in desperate attempts to fix the problem, obviously exacerbating the communication breakdown and gridlock further. It also builds resentment and can turn pretty toxic as everyone starts just looking out for themselves.

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

#255

Post by [deleted] » Mon, Nov 24, 2025, 5:06 PM UTC

[deleted]

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

#256

Post by nsingh2 » Mon, Nov 24, 2025, 5:08 PM UTC

machomaster wrote: post #245

dijksterhuis wrote: post #212

Earlier quoted context omitted.

i got lucky at my last shop. b2b place for like 2x other customer companies. eng manager person (who was also like 3x other managers :/ ) let everything get super broken and unstable. when i took lead of eng it was quite an easy path to making it clear stability was critical. slow everything down and actually do QA. customer became super happy because basically 3x releases went out with minimal bugs/tweaks required.…

It's interesting how misaligned your effort is. You put effort into writing an unnecessary tldr on a short post, but couldn't be bothered to properly Capitalize your sentences in order to ensure the readability. Weird.

> Be kind. Don't be snarky. Edit out swipes [1]

[1] https://news.ycombinator.com/newsguidelines.html

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

#257

Post by hermitcrab » Mon, Nov 24, 2025, 5:15 PM UTC

Alternative title: "We only fix bugs for one week every quarter".

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

#258

Post by ChrisMarshallNY » Mon, Nov 24, 2025, 5:18 PM UTC

bagacrap wrote: post #247

ChrisMarshallNY wrote: post #241

Earlier quoted context omitted.

Depends. If it takes a long time to track down, then it should either be sidelined, or the design needs to be revisited. I have found that really deep bugs are the result of bad design, on my part, and applying "band-aid" fixes often just kicks the can down the road, for a reckoning (that is now just a bit worse), later. If it is not super-serious (small performance issues, for instance; which can involve moving a lo…

> If it takes a long time to track down, then it should either be sidelined, or the design needs to be revisited. I don't get this. Either you give up on the bug after a day, or you throw out the entire codebase and start over? Sure, if the bug is low severity and I don't have a reproduction, I will ignore it. But there are bad bugs that are not understood and can take a lot more than a day to look into, such as by a…

> you throw out the entire codebase and start over

Nah. That’s called “catastrophic thinking.” This is why it’s important (in my experience) to back off, and calm down.

I’ll usually find a way to manage a smaller part of the codebase.

If I make decisions when I’m stressed, Bad Things Happen.

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

#259

Post by asdfman123 » Mon, Nov 24, 2025, 5:21 PM UTC

ls-a wrote: post #56

asdfman123 wrote: post #12

Earlier quoted context omitted.

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

I'm sure it has a lot to do with the complexity of the environment but I've fixed three bugs in a day easily.

Our software isn't serving millions of people though, it's a cli tool with a few hundred end users.

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

#260

Post by michaelbuckbee » Mon, Nov 24, 2025, 5:22 PM UTC

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…

Something I often find are "categorical" bugs where it's really 3 or 4 different bugs in a trench coat all presenting as a single issue.