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

321–330 of 356 posts

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

#321

Post by lovich »

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.

I still have nightmares of load bearing Perl scripts and comlink interops, and then of course our dear friend the GAC

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

#322

Post by BurningFrog »

IgorPartola wrote: post #309
BurningFrog wrote: post #304

Earlier quoted context omitted.

Your argument is only true if you have an infinite number of bugs. If you only have a reasonable number of bugs, and fix them as you find them, it's just how you do work. It may sound impossible, but I did work like this for two decades, and it worked well for those teams.

No. My argument is valid if you have deadlines and your resources are not infinite. Either you were the only one reporting bugs at which point of course you could fix the as you found them because they were always in your work context or you had no deadlines and could afford to switch context without the inefficiency of it affecting anything. In most situations you have users who also find bugs and report them when t…

Well, we clearly come from very different work methodologies.

You have deadlines, velocity is a goal rather than a measurement, and probably several other (IMHO) process mistakes. In such systems, doing what is best for the organization can often be bad for your personal career. Still, that's probably the norm in much of the industry.

My view is that having bugs is costly. They cause problems in development, and alienates users. A bug free code base is an incredible asset to have!

You say it's inefficient to "switch context" and fix a bug the moment you find it. There is some truth there, but... (1) there are ways to work without huge context load, (2) I don't have to fix the bug that very minute. Usually, I make a note and get to it the next day or so. Also (3) the average bug fix in a well structured and tested code base is usually pretty quick.

> If your way was both more efficient AND more aligned with human nature then everyone would be working like this

This assumes the software industry is really well organized. After 40 years experience writing software, that is just hilarious! Though I probably also thought that before I got involved with much better organizations.

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

#323

Post by sfink »

ChrisMarshallNY wrote: post #173
ZaoLahma wrote: post #170

Earlier quoted context omitted.

For me the longer I work, the worse the bugs I work with become. Nowadays, after some 17 years in the business, it's pretty much always intermittently and rarely occurring race conditions of different flavors. They might result in different behaviors (crashes, missing or wrong data, ...), but at the core of it, it's almost always race conditions. The easy and quick to fix bugs never end up with me.

The reward for good work, is more work. I tend to mostly work alone, these days (Chief Cook & Bottle-Washer). All bugs are mine.

What kind of kitchen are you working in where bugs are a concern??!

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

#324

Post by ls-a »

asdfman123 wrote: post #259
ls-a wrote: post #56

Earlier quoted context omitted.

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

I'm sure it has a lot to do with the complexity of the environment but I've fixed three bugs in a day easily. Our software isn't serving millions of people though, it's a cli tool with a few hundred end users.

Good job coloring github squares

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

#325

Post by lalitmaganti »

danielbarla wrote: post #190
lalitmaganti wrote: post #188

Author here! Really glad to have sparked a lively discussion in the comments. Since there is so many threads since I last looked at this post, making one top level comment to provide some thoughts: 1) I agree that estimating a bug's complexity upfront is an error prone process. This is exactly why I say in the post that we encourage everyone to "feel out" non trivial issues and if it feels like the scope is expanding…

Very interesting post, thank you! I'd also be curious to know the following: how many new errors or regressions were caused by the bug fixes?

Since the fixit just finished on Friday, I don't have hard numbers from this one I'm afraid :)

Historically though, I would guess maybe 5-10% end up needing some followup fix which is itself usually smaller than the original (maybe a typo in some documentation or some edge case we spot when it hits prod etc).

The smaller the original fixes, the less likely you are to need followups so another reason to prefer working mainly on them!

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

#326

Post by sfink »

danielbarla wrote: post #190
lalitmaganti wrote: post #188

Author here! Really glad to have sparked a lively discussion in the comments. Since there is so many threads since I last looked at this post, making one top level comment to provide some thoughts: 1) I agree that estimating a bug's complexity upfront is an error prone process. This is exactly why I say in the post that we encourage everyone to "feel out" non trivial issues and if it feels like the scope is expanding…

Very interesting post, thank you! I'd also be curious to know the following: how many new errors or regressions were caused by the bug fixes?

Heh, good question. In the limit: did you fix 12 bugs, or did you fix 1 bug 12 times?

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

#327

Post by int_19h »

kccqzy wrote: post #285
Aurornis wrote: post #274

Earlier quoted context omitted.

All of the buggy software projects I've been employed to work on have had some version of this rule. Usually it's implicit, rather than explicit: Nobody tells you to limit work on bugs to 1-2 days, but if you spend an entire week debugging something difficult and don't accumulate any story points in Jira, a cadre of project manager, program managers, and other manager titles you didn't even know existed will descend…

I hate this kind of management culture that misuses story points. Story points are supposed to take into account difficulty. So if you spend an entire week debugging a difficult bug, you should’ve accumulated about the same amount of story points as colleagues debugging ten easy bugs.

Just about everything about Agile as it is actually practiced IRL by most workplaces is "misuses X".

At some point one can't help but wonder: if almost everyone is "misusing" it, then maybe it's a problem with the methodology itself, and the people for whom it works would have worked just as well organically without it?

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

#328

Post by int_19h »

ChrisMarshallNY wrote: post #70
wahnfrieden wrote: post #38

Earlier quoted context omitted.

LLMs have helped me here the most. Adding copious detailed logging across the app on demand, then inspecting the logs to figure out the bug and even how to reproduce it.

Yes. I often just copy the whole core dump, and feed it into the prompt.

I kinda wonder if at some point this is something we might use the LLM more directly for. As in, train them on raw binary dumps as input.

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

#329

Post by int_19h »

lll-o-lll wrote: post #174
ZaoLahma wrote: post #170

Earlier quoted context omitted.

For me the longer I work, the worse the bugs I work with become. Nowadays, after some 17 years in the business, it's pretty much always intermittently and rarely occurring race conditions of different flavors. They might result in different behaviors (crashes, missing or wrong data, ...), but at the core of it, it's almost always race conditions. The easy and quick to fix bugs never end up with me.

Yep. Non-determinism. Back in the day it was memory corruption caused by some race condition. By the time things have gone pop, you’re too far from the proximate cause to have useful logs or dumps. “Happens only once every 100k runs? Won’t fix”. That works until it doesn’t, then they come looking for the poor bastard that never fixes a bug in 2 days.

The worst bug in my career was when the app would reliably crash if you left it running for "long enough" - but still non-probabilistically, so sometimes it would happen in an hour, sometimes in three. The crash itself was quickly diagnosed as a corrupt vtable, but finding the piece of code that had a pointer bug in it that just happened to write into (some) object's vtable in certain situations that triggered a race condition took many days.

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

#330

Post by wavemode »

RHSeeger wrote: post #317
AdamN wrote: post #209

Earlier quoted context omitted.

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

But it's not "wont fix", because it will get fixed when there's nothing of a higher priority. And it's priority could change at some point. > Better to have a policy of always fixing bugs but be more flexible on what counts as a bug I just disagree with this. It's entirely possible for something to not work correctly, but that fact be unimportant at the moment (or less important than something else).

The philosophy of fixing bugs first before implementing new features is not that the bugs you're fixing must be more "important" than the new features.

In fact, that's exactly the mindset that "bugs first" is designed to prevent. If you have a mindset where a bug has to be more important than a feature in order to get prioritized, then you will breed a culture in which bugs are rarely prioritized, if ever. (Especially if fixing them would be time-consuming.)

This is for the simple reason that, in isolation, any individual feature can almost always be argued to be more important than any individual bug which could've been worked on instead. Yet, in the aggregate, once you've dumped 50 individual low-priority bugs into the backlog, they all add up to a horrendous experience for the user.

It's sort of like running a restaurant. Cooking food is how we make money, but you still have to clean the floors. If you keep putting it off to get the food out faster, eventually you're going to be knee-deep in shit.

Post reply on HN