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

221–230 of 356 posts

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

#221

Post by peepee1982 »

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…

Yep. Also, sometimes you figure out a bug and in the process you find a whole bunch of new ones that the first bug just never let surface.

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

#222

Post by CharlieDigital »

2arrs2ells wrote: post #214
IgorPartola wrote: post #204

Earlier quoted context omitted.

Say you are working on a banking system. You ship a login form, it is deployed, used by tons of people. Six months later you are mid-sprint on the final leg of a project that will hook your bank into the new FedNow system. There are dozens of departments working together to coordinate deploying this new setup as large amounts of money will be moved through it. You are elbows deep in the context of your part of this a…

This is a great example... except I think the right answer to "what exactly would you do in this case?" doesn't support your argument. I'd document that mobile Opera with Javascript disabled is an unsupported config, and ask a team to make a help center doc asking mobile Opera users to enable JS.

This is too logical, practical, and pragmatic. Which product owner/project manager would approve such a thing!?

Being able to think of simple, practical solutions like this is one of the hardest skills to develop as a team, IMO. Not everything needs to be perfect and not everything needs a product-level fix. Sometimes a "here's the workaround" is good enough and if enough people complain or your metrics show use friction in some journey, then prioritize the fix.

GP's example is so niche that it isn't worth fixing without evidence that the impact is significant.

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

#223

Post by bluGill »

huherto wrote: post #210
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 do agree that you should be able to fix most bugs in 2 days or less. If you have many bugs taking longer to fix, it may be an indication that you may have systemic issues. (e.g design, architectural, tooling, environment access, test infrastructure, etc)

Sure, but you never know if this next bug is another fix it in 1 hour, or it will take months to figure out. I have had a few "The is not spelled 'Teh'" bugs that it takes longer to find the code in question with grep than to fix, but most are a not that obvious and so you don't know if there are 2 hours left or not until 2 hours latter when you know you found something or are still looking. (or unless you think you fixed it and the time to verify the test is about 2 hours, but then only if your fix worked)

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

#225

Post by bluGill »

wahnfrieden wrote: post #38
chii wrote: post #20

Earlier quoted context omitted.

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.

I did that once: logging ended up taking 80% of the CPU leaving not enough overhead for everything else the system should do. Now I am more careful to figure out what is worth logging at all, and also to make sure disabled logs are quickly bypassed.

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

#226

Post by tracker1 »

I've been pushing for things like this for years...

Having every 3rd or 4th sprint being dev initiatives and bugs... Or having a long/short sprint cycle where short sprints are for bugs mostly... Basically every 3rd week is for meetings and bug work so you get a solid 2 weeks with reduced meetings.

It's hard to convince upper managers of the utility though.

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

#227

Post by sb8244 »

zelphirkalt wrote: post #157
sb8244 wrote: post #6

Earlier quoted context omitted.

If the bug affects 1 customer and the feature affects the rest, is the old feature complete? It's not binary.

Yet engineers are pushed to give unknowable estimates of points and when things take "longer" (did you notice that shift right there?) they are either overdue, taking too long, or they don't, and to say: "It takes as long as it takes." is not accepted by middle management.

That's a strawman. It is not really related to the main point and I'm not sure of the point you're trying to make (maybe that tension exists?)

Obviously things take as long as they take. I've always been an educator of this back to the business leadership. In my experience, most business people truly have no freaking clue how a product gets built and code gets shipped.

Giving proactive updates (meaning not the day it was expected to be done according to last update) are important part of a professionals working life. There's always a tension between business and engineers. Engineers just generally don't do that well with tension and try to minimize it, or complain about it.

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

#228

Post by jorvi »

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…

Yeah, "no bug should take over 2 days" tells me you've never had a race condition in your codebase.

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

#229

Post by chrisweekly »

HelloNurse wrote: post #162
fransje26 wrote: post #121

Earlier quoted context omitted.

> 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 [..] And then comes the "beginner's" mistake. They don't seem to be doing anything. Let's remove them, what could possibly go wrong?

If you follow the prescribed procedure and involve all required management, it stops being a beginner's mistake; and given reasonable rollback provisions it stops being a mistake at all because if nobody knows what the thing is it cannot be very important, and a removal attempt is the most effective and cost efficient way to find out whether the ting can be removed.

Well, maybe. See Chesterson's Fence^1

[1] https://theknowledge.io/chestertons-fence-explained/

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

#230

Post by jeffreygoesto »

QuiEgo wrote: post #213
QuiEgo wrote: post #207

Earlier quoted context omitted.

As someone who works with hardware, hard to repo bugs can take months to track down. Your code, the compiler, or the hardware itself (which is often a complex ball of IP from dozens of manufacturers held together with a NoC) could all be a problem. The extra fun bugs are when a bug is due to problems in two or three of them combining together in the perfect storm to make a mega bug that is impossible to reproduce in…

Random example: I once worked on a debug where you were not allowed to send zero length packets due to a known HW bug. Okay fine, work around in SW. Turns out there was an HW eviction timer that was disabled. It was connected to a counter that counted sys clk ticks. Turns out it was not disabled entirely properly due to SW bug, so once every 2^32 ticks, it would trigger an evection, and if the queue happened to be em…

We had one where data, interpreted as address (simple C typo before static analysis was common) fell into an unmapped memory region and the PCI controller stalled trying to get a response, thereby also halting the internal debugging logic and JTAG just stopped forever (PPC603 core). Each time you'd hit the bug, the debugger was thrown off.
Post reply on HN