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

71–80 of 356 posts

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

#71

Post by triyambakam »

com2kid wrote: post #60
triyambakam wrote: post #58

Earlier quoted context omitted.

I just find it so oversimplified that I can't believe you're sincere. Like you have entirely no internal heuristic for even a coarse estimation of a few minutes, hours, or days? I would say you're not being very introspective or are just exaggerating.

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.

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

#72

Post by auguzanellato »

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.

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

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

#73

Post by ChrisMarshallNY »

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.

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.

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

#74

Post by ls-a »

toast0 wrote: post #65
ls-a wrote: post #56

Earlier quoted context omitted.

Nothing takes 2 days to fix. Those are definitely not bugs, like someone else mentioned

You haven't seen the same kind of bugs I have, I guess. This kind of thing takes more than 2 days to fix, unless you're really good. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637 Or this one https://security.stackexchange.com/questions/104845/dhe-rsa-... I can find more of these that I've run into if I look. I've had tricky bugs in my team's code too, but those don't result in public artifacts, and I'm res…

That's what I'm saying. Nothing takes 2 days to fix meaning it takes more time

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

#75

Post by BurningFrog »

ben0x539 wrote: post #39
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!!

In your experience, is there a lot of contention over whether a given issue counts as a bug fix or a feature/improvement? In the article, some of the examples were saving people a few clicks in a frequent process, or updating documentation. Naively, I expect that in an environment where bug fixes get infinite priority, those wouldn't count as bugs, so they would potentially stick around forever too.

In my world, improving the UI to save clicks is a new feature, not a bug fix.

Assuming it works as intended.

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

#76

Post by ChrisMarshallNY »

OhMeadhbh wrote: post #55
ChrisMarshallNY wrote: post #24

Earlier quoted context omitted.

In that case, maybe having bug fixing be a two-step process (identify, then fix), might be sensible.

I do this frequently. But sometimes identifying and/or fixing takes more than 2 days. But you hit on a point that seems to come up a lot. When a user story takes longer than the alloted points, I encourage my junior engineers to split it into two bugs. Exactly like what you say... One bug (or issue or story) describing what you did to typify the problem and another with a suggestion for what to do to fix it. There do…

You sound like a great team leader.

Wish there were more like you, out there.

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

#77

Post by [deleted] »

waste_monk wrote: post #44
jaredsohn wrote: post #35

Earlier quoted context omitted.

I'd love to see an actual bug-free codebase. People who state the codebase in bug-free probably just lack awareness. Even stating we 'have only x bugs' is likely not true.

>I'd love to see an actual bug-free codebase. cat /dev/null .

[deleted]

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

#78

Post by skylurk »

jaredsohn wrote: post #35
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!!

I'd love to see an actual bug-free codebase. People who state the codebase in bug-free probably just lack awareness. Even stating we 'have only x bugs' is likely not true.

https://github.com/kelseyhightower/nocode

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

#79

Post by jaredklewis »

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 classifying whatever they wanted done as a bug (and the line can be somewhat blurry anyway). So curious if that was an issue that needed dealing with.

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

#80

Post by troad »

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 to software dev as the idea of fair dealing is to used car salesmen.

Post reply on HN