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

21–30 of 356 posts

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

#21

Post by kykat »

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.

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

#23

Post by kykat »

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 the places that I worked, features came before all else, and bugs weren't fixed unless customers complain

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

#24

Post by ChrisMarshallNY »

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.

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

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

#25

Post by lapcat »

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…

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

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

#26

Post by kykat »

asdfman123 wrote: post #12
ls-a wrote: post #10

189 bugs in one week. How many employees quit after that?

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.

Too bad many places care more about how long you stay warming the seat than how useful the work done actually is.

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

#27

Post by triyambakam »

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…

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

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

#28

Post by wredcoll »

jchrisa wrote: post #18

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…

I would be weirdly happy to have a role whose entire job was literally just deleting code. It is extremely satisfying.

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

#29

Post by lapcat »

superxpro12 wrote: post #9
xnx wrote: post #5

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.

until we develop a way for MBA's with spreadsheets to quantify profit/loss w.r.t. bugs, it will never be valued.

The solution is to never hire an MBA.

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

#30

Post by ChrisMarshallNY »

triyambakam wrote: post #27
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…

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

Yeah, I’m obviously a terrible programmer. Ya got me.
Post reply on HN