We stopped roadmap work for a week and fixed 189 bugs
55 points
1 hour ago
| 10 comments
| lalitm.com
| HN
ChrisMarshallNY
21 minutes ago
[-]
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 quite easy to find.

Once I find the cause of a bug, the fix is usually just around the corner.

reply
kykat
17 minutes ago
[-]
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.

reply
ChrisMarshallNY
14 minutes ago
[-]
In that case, maybe having bug fixing be a two-step process (identify, then fix), might be sensible.
reply
PaulKeeble
6 minutes ago
[-]
Sometimes you find the cause of the bug in 5 minutes because its precisely where you thought it was, sometimes its not there and you end up writing some extra logging to hopefully expose its cause in production after the next release because you can't reproduce as its transient. I don't know how to predict how long a bug will take to reproduce and track down and only once its understood do we know how long it takes to fix.
reply
chii
18 minutes ago
[-]
I find most bugs take less time to fix than it takes time to verify and reproduce.
reply
triyambakam
13 minutes ago
[-]
> It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done.

Now I find that odd.

reply
gyomu
10 minutes ago
[-]
I don’t. I worked on firmware stuff where unexplainable behavior occurs; digging around the code, you start to feel like it’s going to take some serious work to even start to comprehend the root cause; and suddenly you find the one line of code that sets the wrong byte somewhere as a side effect, and what you thought would fill up your week ended up taking 2 hours.

And sometimes, the exact opposite happens.

reply
ChrisMarshallNY
11 minutes ago
[-]
Yeah, I’m obviously a terrible programmer. Ya got me.
reply
lapcat
13 minutes ago
[-]
> It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done.

This is explained later in the post. The 2 day hard limit is applied not to the estimate but rather to the actual work: "If something is ballooning, cut your losses. File a proper bug, move it to the backlog, pick something else."

reply
ChrisMarshallNY
7 minutes ago
[-]
Most of the work in finding/fixing bugs is reproducing them reliably enough to determine the root cause.

Once I find a bug, the fix is often negligible.

But I can get into a rabbithole, tracking down the root cause. I don’t know if I’ve ever spent more than a day, trying to pin down a bug, but I have walked away from rabbitholes, a couple of times. I hate doing that. Leaves an unscratchable itch.

reply
BurningFrog
27 minutes ago
[-]
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!!

reply
Celeo
19 minutes ago
[-]
Depending on the size of the team/org/company, working on anything other than the next feature is a hard sell to PM/PO/PgM/management.
reply
kykat
15 minutes ago
[-]
In the places that I worked, features came before all else, and bugs weren't fixed unless customers complain
reply
MrDarcy
21 minutes ago
[-]
Rare indeed.
reply
hastily3114
27 minutes ago
[-]
We do this too sometimes and I love it. When I work on my own projects I always stop and refactor/fix problems before adding any new features. I wish companies would see the value in doing this

Also love the humble brag. "I've just closed my 12th bug" and later "12 was maximum number of bugs closed by one person"

reply
julianlam
58 minutes ago
[-]
We did this ages ago at our company (back then we were making silly Facebook games, remember those?)

It was by far the most fun, productive, and fulfilling week.

It went on to shape the course of our development strategy when I started my own company. Regularly work on tech debt and actively applaud it when others do it too.

reply
xnx
47 minutes ago
[-]
I've never understood why bugs get treated differently from new features. If there was a bug, the old feature was never completed. The time cost and benefits should be considered equally.
reply
sb8244
45 minutes ago
[-]
If the bug affects 1 customer and the feature affects the rest, is the old feature complete?

It's not binary.

reply
klodolph
44 minutes ago
[-]
Bugs can get introduced for other reasons besides “feature not completed”.
reply
superxpro12
38 minutes ago
[-]
until we develop a way for MBA's with spreadsheets to quantify profit/loss w.r.t. bugs, it will never be valued.
reply
lapcat
12 minutes ago
[-]
The solution is to never hire an MBA.
reply
jchrisa
19 minutes ago
[-]
I just had a majorly fun time addressing tech debt, deleting about 15k lines-of-code from a codebase that now has ~45k lines of implementation, and 50k lines of tests. This was made possible by moving from a homegrown auth system to Clerk, as well as consolidating some Cloudflare workers, and other basic stuff. Not as fun as creating the tech debt in the first place, but much more satisfying. Open source repo if you like to read this sort of thing: https://github.com/VibesDIY/vibes.diy/pull/582
reply
wredcoll
12 minutes ago
[-]
I would be weirdly happy to have a role whose entire job was literally just deleting code. It is extremely satisfying.
reply
tait1
16 minutes ago
[-]
We’ve done little mini competitions like this at my company, and it’s always great for morale. Celebrating tiny wins in a light, semi-competitive way goes a long way for elevating camaraderie. Love it!
reply
entropie
43 minutes ago
[-]
I wanted to take a look at some of these bug fixes, and one of the linked ones [1] seems more like a feature to me. So maybe it should be the week of "low priority" issues, or something like that.

I don't mean to sound negative, I think it's a great idea. I do something like this at home from time to time. Just spend a day repairing and fixing things. Everything that has accumulated.

1: https://github.com/google/perfetto/issues/154

reply
mulquin
34 minutes ago
[-]
To be fair, the blog post does not explicitly say anywhere that the week was for bug fixes only.
reply
kangs
3 minutes ago
[-]
hello b/Googler :)
reply
ls-a
36 minutes ago
[-]
189 bugs in one week. How many employees quit after that?
reply
asdfman123
33 minutes ago
[-]
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.

reply
kykat
13 minutes ago
[-]
Too bad many places care more about how long you stay warming the seat than how useful the work done actually is.
reply
Normal_gaussian
32 minutes ago
[-]
189 presumably
reply