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

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

#101

Post by snovv_crash » Mon, Nov 24, 2025, 7:46 AM UTC

com2kid wrote: post #89

triyambakam wrote: post #71

Earlier quoted context omitted.

But what was the original estimate? And even so I'm not saying it must be completely and always correct. I'm saying it seems wild to have no starting point, to simply give up.

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 the bug.

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

#102

Post by stevoski » Mon, Nov 24, 2025, 7:48 AM UTC

I’m a strong believer in “fix bugs first” - especially in the modern age of “always be deploying” web apps.

(I run a small SaaS product - a micro-SaaS as some call it.)

We’ll stop work on a new feature to fix a newly reported bug, even if it is a minor problem affecting just one person.

Once you have been following a “fix bugs first” approach for a while, the newly discovered bugs tend to be few, and straight forward to reproduce and fix.

This is not necessarily the best approach from a business perspective.

But from the perspective of being proud of what we do, of making high quality software, and treating our customers well, it is a great approach.

Oh, and customers love it when the bug they reported is fixed within hours or days.

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

#103

Post by ozim » Mon, Nov 24, 2025, 7:48 AM UTC

remus wrote: post #86

troad wrote: post #80

It's fairly telling of the state of the software industry that the exotic craft of 'fixing bugs' is apparently worth a LinkedIn-style self-promotional blog post. I don't mean to be too harsh on the author. They mean well. But I am saddened by the wider context, where a dev posts 'we fix bugs occasionally' and everyone is thrilled, because the idea of ensuring software continues to work well over time is now as alien…

> But I am saddened by the wider context, where a dev posts 'we fix bugs occasionally' and everyone is thrilled, because the idea of ensuring software continues to work well over time is now as alien to software dev as the idea of fair dealing is to used car salesmen This is not the vibe I got from the post at all. I am sure they fix plenty of bugs throughout the rest of the year, but this will be balanced with other…

That’s what we have fix anything Friday for.

The name is just an indication you can do it any day but idea is on Friday when you are at no point to start big thing, pick some small one you want to fix personally. Maybe a big in product maybe local dev setup.

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

#104

Post by jll29 » Mon, Nov 24, 2025, 7:51 AM UTC

From the report, it sounds like a good thing, for the product and the team morale.

Strangely the math looks such that they could hire nearly 1 FTE engineer that works full time only on "little issues" (40 weeks, given that people have vacations and public holidays and sick time that's a full year's work at 100%), and then the small issues could be addressed immediately, modulo the good vibes created by dedicating the whole group to one cause for one week. Of course nobody would approve that role...

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

#105

Post by eviks » Mon, Nov 24, 2025, 7:52 AM UTC

> closed a feature request from 2021! > It’s a classic fixit issue: a small improvement that never bubbled to the priority list. It took me one day to implement. One day for something that sat there for four years

> The benefits of fixits

> For the product: craftsmanship and care

sorry, but this is not care when the priority system is so broken that it requires a full suspension, but only once a quarter

> A hallmark of any good product is attention to detail:

That's precisely the issue, taking 4 years to bring attention to detail, and only outside the main priority system.

Now, don't get me wrong, a fixit is better than nothing and having 4 year bugs turn into 40 year ones, it's just that this is not a testament of craftsmanship/care/attention to detail

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

#106

Post by ivolimmen » Mon, Nov 24, 2025, 8:06 AM UTC

stevoski wrote: post #102

I’m a strong believer in “fix bugs first” - especially in the modern age of “always be deploying” web apps. (I run a small SaaS product - a micro-SaaS as some call it.) We’ll stop work on a new feature to fix a newly reported bug, even if it is a minor problem affecting just one person. Once you have been following a “fix bugs first” approach for a while, the newly discovered bugs tend to be few, and straight forward…

Would love to work on a project with this as a rule but I am working on a project that was build before me with 1.2 million lines of code, 15 years old, really old frameworks; I don't think we could add features if we did this.

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

#107

Post by arkh » Mon, Nov 24, 2025, 8:12 AM UTC

kykat wrote: post #21

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, 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.

> Sometimes, a "bug" can be caused by nasty architecture with intertwined hacks

The joys of enterprise software. When searching for the cause of a bug let you discover multiple "forgotten" servers, ETL jobs, crons all interacting together. And no one knows why they do what they do how they do. Because they've gone away many years ago.

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

#108

Post by snovv_crash » Mon, Nov 24, 2025, 8:22 AM UTC

heyitsdaad wrote: post #85

False sense of accomplishment. Doing what you want to do instead of what you should doing (hint: you should be busy making money). Inability to triage and live with imperfections. Not prioritizing business and democratizing decision making.

Just because you can't measure the loss of customers who are turned off by your buggy product doesn't mean they don't exist.

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

#109

Post by pyrale » Mon, Nov 24, 2025, 8:29 AM UTC

triyambakam wrote: post #71

com2kid wrote: post #60

Earlier quoted context omitted.

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 d…

But what was the original estimate? And even so I'm not saying it must be completely and always correct. I'm saying it seems wild to have no starting point, to simply give up.

There is a divide in this job between people who can always provide an estimate but accept that it is sometimes wrong, and people who would prefer not to give an estimate because they know it’s more guess than analysis.

You seem to be in the first club, and the other poster in the second.

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

#110

Post by [deleted] » Mon, Nov 24, 2025, 8:38 AM UTC

RHSeeger wrote: post #57

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.

[deleted]