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

161–170 of 356 posts

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

#161

Post by ljm »

fragmede wrote: post #142
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?

that's a management/cultural problem. if no one knows why it's there, the right answer is to remove it and see what breaks. If you're too afraid to do anything, for nebulous cultural reasons, you're paralyzed by fear and no one's operating with any efficiency. It hits different when it's the senior expert that everyone revere's that invented everything the company depends on that does it, vs a summer intern vs Elon M…

This does depend on a certain level of testing (automated or otherwise) for you to even be able to identify what breaks in the first place. The effect might be indirect several times over and you don't see what has changed until it lands in front of a customer and they notice it right away.

Move fast and break things is also a managerial/cultural problem in certain contexts.

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

#162

Post by HelloNurse »

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?

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.

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

#163

Post by invalidusernam3 »

I like the idea of this, but why not just have some time per week/sprint for bugs? At my company we prioritise features, but we also take some bug tickets every sprint (sometimes loads of bug tickets if there aren't many new features ready for dev), and generally one engineer is on "prod support" which means tackling bugs as they get reported

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

#164

Post by stuartjohnson12 »

invalidusernam3 wrote: post #163

I like the idea of this, but why not just have some time per week/sprint for bugs? At my company we prioritise features, but we also take some bug tickets every sprint (sometimes loads of bug tickets if there aren't many new features ready for dev), and generally one engineer is on "prod support" which means tackling bugs as they get reported

Because marginal work is only marginally rewarded. Spending one week and coming back to whoever with a nice piece of paper saying we fixed 60 bugs will earn a lot more rope from non-technical folk than fixing 3 bugs per week - the latter just looks like cleaning up your incompetence.

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

#165

Post by watty »

neilv wrote: post #50

> We also have a “points system” for bugs and a leaderboard showing how many points people have. [...] It’s a simple structure, but it works surprisingly well. What good and bad experiences have people had with software development metrics leaderboards?

I've never had a good experience with individual metrics leaderboards. On one team we had a JIRA story point tracker shown on a tv by a clueless exec. Devs did everything they could to game the system and tasks that required uncertainty (hard tasks) went undone. I believe it contributed to the cog culture that caused an exodus of developers.

However, I love the idea of an occasional team based leaderboard for an event. I've held bug and security hackathons with teams of 3-5 and have had no problem with them.

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

#166

Post by groestl »

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.

And then it turns out the bug is actually very intentional behavior.

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

#167

Post by ChrisMarshallNY »

tonyedgecombe wrote: post #114
Uehreka wrote: post #54

Earlier quoted context omitted.

> It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. In my experience there are two types of low-priority bugs (high-priority bugs just have to be fixed immediately no matter how easy or hard they are). 1. The kind where I facepalm and go “yup, I know exactly what that is”, though sometimes it’s too low of a priority to do it right now, and it ends up sitting on th…

>high-priority bugs just have to be fixed immediately no matter how easy or hard they are The fact that something is high priority doesn't make it less work.

Or more.

I often find the nastiest bugs are the quickest fixes.

I have a "zero-crash" policy. Crashes are never acceptable.

It's easy to enforce, because crashes are usually easy to find and fix.

$> ThreadingProblems has entered the chat

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

#168

Post by auggierose »

darkwater wrote: post #148
auggierose wrote: post #141

Earlier quoted context omitted.

I can explain it to you. A bug description at the beginning is some observed behaviour that seems to be wrong. Now the process starts of UNDERSTANDING the bug. Once that process has concluded, it will be possible to make a rough guess of how long fixing it will take. Very often, the answer then is a minute or two, unless major rewrites are necessary. So, the problem is you cannot put an upfront bound on how long you…

> A bug description at the beginning is some observed behaviour that seems to be wrong. Or not. A bug description can also be a ticket from a fellow engineer who knows the problem space deeply and have an initial understanding of the bug, likely cause and possible problems. As always, it depends, and IME the kind of bugs that end up in those "bugathons" are the annoying "yeah I know about it, we need to fix it at som…

That just means that somebody else has already started the process of understanding the bug, without finishing it. So what?

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

#169

Post by kubb »

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.

You might get humbled by overwhelming complexity one day. Enjoy the illusion of perfect insight until then.

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

#170

Post by ZaoLahma »

ChrisMarshallNY wrote: post #136
ZaoLahma wrote: post #134

Earlier quoted context omitted.

> That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. The longer I work as a software engineer, the rarer it is that I get to work with bugs that take only a day to fix.

I've found the opposite to be true, in my case.

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.

Post reply on HN