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

201–210 of 356 posts

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

#201

Post by w0m »

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…

> That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one.

oh sweet sweet summer child...

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

#202

Post by Retric »

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.

> a removal attempt is the most effective and cost efficient way to find out whether the ting can be removed

Cost efficient for your team’s budget sure, but a 1% chance of a 10+ million dollar issue is worth significant effort. That’s the thing with enterprise systems the scale of minor blips can justify quite a bit. If 1 person operating for 3 months could figure out what something is doing there’s scales where that’s a perfectly reasonable thing to do.

Enterprise covers a while range of situations there’s a lot more billion dollar orgs than trillion dollar orgs so your mileage may very.

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

#203

Post by cracki »

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…

Symptoms of a dysfunctional company where communication has broken down, everyone with any authority is running around EXACTLY like a headless chicken, waving around frantically (giving orders). Margins are probably thin as a razor, or non-existent. They will micromanage your work time to death. You will be treated as a commodity factory machine and if you start using your brain to solve actual problems, you will be chastised. Deadlines everywhere keep everyone's brain shut off and in panic mode. No time to properly engineer anything. Nobody has the time to check anyone else's work, causing "trust" that isn't even blind, just foolish. You as the software guy end up debugging and fixing EVERYONE's mistakes. When the bug is in hardware/electronics, everyone knows who's actually to blame, but everyone still expects YOU to fix it, and they're immensely disappointed when you can't save the day.

These places cannot and will not change. If you can, find employment elsewhere.

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

#204

Post by IgorPartola »

gregoriol wrote: post #175
demaga wrote: post #151

Earlier quoted context omitted.

From the post: > That’s not to say we don’t fix important bugs during regular work; we absolutely do. But fixits recognize that there should be a place for handling the “this is slightly annoying but never quite urgent enough” class of problems. So in their case, fixit week is mostly about smaller bugs, quality of life improvements and developer experience.

It must be part of the normal process. If the normal process leaves things like this to "some other time", one should start by fixing the process.

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 and the system cannot go live without it. Twice a day you are getting QA feedback and need to make prompt updates to your code so the work doesn’t stall.

This is when the report comes in that your login form update from six months ago does not work on mobile Opera if you disable JavaScript. The fix isn’t obvious and will require research, potentially many hours or even days of testing and since it is a login form you will need the QA team to test it after you find another developer on your team to do a code review for you.

What exactly would you do in this case? Pull resources from a major project that has the full attention of the C suite to accommodate some tin foil Luddite a few weeks sooner or classify this as lower priority?

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

#205

Post by xnorswap »

fransje26 wrote: post #121
arkh wrote: post #107

Earlier quoted context omitted.

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

> 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?

The next mistake is thinking that completely re-writing the system will clean out the cruft.

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

#206

Post by enraged_camel »

ChrisMarshallNY wrote: post #131
Lionga wrote: post #95

Earlier quoted context omitted.

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

Nope. Good result == LLM + Experience. The LLM just reduces the overhead. That’s really what every “new paradigm” has ever done.

Also, robust test coverage helps prevent regressions.

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

#207

Post by QuiEgo »

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…

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

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

#208

Post by AdamN »

mentos wrote: post #196
etamponi wrote: post #145

Ex-Meta employee here. I worked at reality labs, perhaps in other orgs the situation is different. At Meta we did "fix-it weeks", more or less every quarter. At the beginning I was thrilled: leadership that actually cares about fixing bugs! Then reality hit: it's the worst possible decision for code and software quality. Basically this turned into: you are allowed to land all the possible crap you want. Then you have…

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.

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

#209

Post by AdamN »

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.

IMHO the best way to deal with that situation is to mark the bug as wontfix. Better to have a policy of always fixing bugs but be more flexible on what counts as a bug (and making sure the list of them is very small and being actively worked on).

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

#210

Post by huherto »

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)
Post reply on HN