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

121–130 of 356 posts

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

#121

Post by fransje26 »

arkh wrote: post #107
kykat wrote: post #21

Earlier quoted context omitted.

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.

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

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

#122

Post by sshine »

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…

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

Race conditions in 3rd party services during / affected by very long builds and with poor metrics and almost no documentation. They only show up sometimes, and you have to wait for it to reoccur. Add to this a domain you’re not familiar with, and your ability to debug needs to be established first.

Stack two or three of these on top of each other and you have days of figuring out what’s going on, mostly waiting for builds, speculating how to improve debug output.

After resolving, don’t write any integration tests that might catch regressions, because you already spent enough time fixing it, and this needs to get replaced soon anyway (timeline: unknown).

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

#123

Post by alkonaut »

We once did this for a massive product with 3 releases per year: took a whole cycle to do zero features, and just fix bugs. Internal customers who usually stepped over themselves to get their latest feature in the program, were accepting it. But we had to announce it early. Otherwise the usual consensus is that customers would rather take 1 feature together with 10 new bugs, than -5 bugs and no new features.

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

#124

Post by abroszka33 »

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…

> did anybody have had this kind of experience?

Yes, the issue is not you, it's a toxic workplace. Leave as soon as you can.

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

#125

Post by marginalia_nu »

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 think in general, bugs go unfixed in two scenarios:

1. The cause isn't immediately obvious. In this case, finding the problem is usually 90% of the work. Here it can't be known how long finding the problem is beforehand, though I don't think bailing because it's taking too long is a good idea. If anything, it's those really deep rabbit holes the real gremlins can hide.

2. The cause is immediately obvious, but is an architecture mistake, the fix is a shit-ton of work, breaks workflows, requires involving stakeholders, etc. Even in this case it can be hard to say how long it will take, especially if other people are involved and have to sign off on decisions.

I suppose it can also happen in low-trust sweatshops where developers held on such a tight leash they aren't able to fix trivial bugs they find without first going through a bunch of jira rigmarole, which is sort of low key the vibe I got from the post.

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

#126

Post by pjc50 »

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…

This is not uncommon but I've mostly managed to avoid it, because it's a management failure. There is a delicate process of "managing the customer" so that they get a result they will eventually be satisfied with, rather than just saying yes to whatever the last phone call was.

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

#127

Post by zelphirkalt »

jaredklewis wrote: post #79
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 classi…

Frontend bugs mostly stem from usage of overblown frontend frameworks, that try to abstract from the basics of the web too much. When relying on browser defaults and web standards, proper semantic HTML and sane CSS usage, the scope of things that can go wrong is limited.

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

#128

Post by ramon156 »

BurningFrog wrote: post #36
Celeo wrote: post #19

Earlier quoted context omitted.

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.

That's what I hear. I've had some mix of luck and skill in finding these jobs. Working with people you've worked with before helps with knowing what you're in for. I also don't really ask anyone, I just fix any bugs I find. That may not work in all organizations :)

I can guarantee you this doesn't work in our team! you didn't make a ticket, so the PM has no idea what you're doing!

Yes, a ticket takes 2 seconds. it also puts me off my focus :P but i guess measuring is more important than achieving

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

#129

Post by pjc50 »

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 think the worst case I encountered was something like two years from first customer report to even fully confirming the bug, followed by about a month of increasingly detailed investigations, a robot, and an osciliscope.

The initial description? "Touchscreen sometimes misses button presses".

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

#130

Post by ChrisMarshallNY »

plq wrote: post #82
ChrisMarshallNY wrote: post #73

Earlier quoted context omitted.

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.

ICE meaning in-circuit emulator in this instance, I assume?

Yeah. Guess it’s kind of a loaded acronym, these days.
Post reply on HN