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

241–250 of 356 posts

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

#241

Post by ChrisMarshallNY »

thfuran wrote: post #239
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 can’t imagine spending more than a day on one. You mean starting after it has been properly tracked down? It can often take a whole lot of time to go from "this behavior is incorrect sometimes" to "and here's what need to change".

Depends. If it takes a long time to track down, then it should either be sidelined, or the design needs to be revisited.

I have found that really deep bugs are the result of bad design, on my part, and applying "band-aid" fixes often just kicks the can down the road, for a reckoning (that is now just a bit worse), later.

If it is not super-serious (small performance issues, for instance; which can involve moving a lot of cheese), I can often schedule a design review for a time when it's less critical, and maybe set up an exploration branch.

People keep bringing up threading and race conditions, which are legitimately nasty bugs.

In my experience, they are often the result of bad design, on my part. It's been my experience that "thread everything" can be a recipe for disaster. The OS/SDK will often do internal threading, and I can actually make things worse, by running my own threads.

I try to design stuff that will work fine, in any thread, which gives me the option to sequester it into a new thread, at a later time (I just did exactly that, a few days ago, in a Watch app), but don't immediately do that.

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

#242

Post by briandrum »

brightball wrote: post #189

Getting ready to do a December “Bug Smash” based on the model in the book Shape Up. Whole team has been eagerly awaiting it for months.

Shape Up was my first thought too. I just left a team where I introduced cycles of six weeks of feature development and two weeks of bug fixing, tech debt, and anything else the developers decided to tackle.

It depends on the stage and size of your team and company of course, but for us the result was more predictable delivery and happier, more-engaged developers.

For anyone curious to learn more: https://basecamp.com/shapeup/2.2-chapter-08#cool-down

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

#243

Post by BurningFrog »

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…

I worked at various small agile startups around SF. Retired last year.

They weren't big enough to have "official policies". We talked to each other instead.

I did work a few years at big companies twice. That taught me to appreciate the simple life :)

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

#244

Post by HelloNurse »

Retric wrote: post #202
HelloNurse wrote: post #162

Earlier quoted context omitted.

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.

> a removal attempt is the most effective and cost efficient way to find out whether the ting can be removed Cost efficient for your team’s budget sure, but a 1% chance of a 10+ million dollar issue is worth significant effort. That’s the thing with enterprise systems the scale of minor blips can justify quite a bit. If 1 person operating for 3 months could figure out what something is doing there’s scales where that…

If there is a risk of a 10+ million dollar issue there is also some manager whose job is to overreact when they hear the announcement that someone wants to eliminate thing X, because they know that thing X is a useful part of the systems they are responsible for.

In a reasonable organization only very minor systems can be undocumented enough to fall through the cracks.

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

#245

Post by machomaster »

dijksterhuis wrote: post #212
NegativeK wrote: post #48

Earlier quoted context omitted.

I've had to inform leadership that stability is a feature, just like anything else, and that you can't just expect it to happen without giving it time. One leader kind of listened. Sort of. I'm pretty sure I was lucky.

i got lucky at my last shop. b2b place for like 2x other customer companies. eng manager person (who was also like 3x other managers :/ ) let everything get super broken and unstable. when i took lead of eng it was quite an easy path to making it clear stability was critical. slow everything down and actually do QA. customer became super happy because basically 3x releases went out with minimal bugs/tweaks required.…

It's interesting how misaligned your effort is.

You put effort into writing an unnecessary tldr on a short post, but couldn't be bothered to properly Capitalize your sentences in order to ensure the readability.

Weird.

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

#246

Post by zeroCalories »

pjmlp wrote: post #219
zeroCalories wrote: post #217

Earlier quoted context omitted.

I don't think titles are for anything besides establishing blame. If a company hires someone in a local where the engineer can't be held responsible, the executives and major investors should be held liable. That way things will naturally sort themselves out. Need something unimportant done? Offshore. Have some critical system? Hire someone that can take responsibility.

As we say back home, responsability should never die alone.

The easiest way to get away with murder is to split the blame such that no individual can be pointed to.

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

#247

Post by bagacrap »

ChrisMarshallNY wrote: post #241
thfuran wrote: post #239

Earlier quoted context omitted.

>I can’t imagine spending more than a day on one. You mean starting after it has been properly tracked down? It can often take a whole lot of time to go from "this behavior is incorrect sometimes" to "and here's what need to change".

Depends. If it takes a long time to track down, then it should either be sidelined, or the design needs to be revisited. I have found that really deep bugs are the result of bad design, on my part, and applying "band-aid" fixes often just kicks the can down the road, for a reckoning (that is now just a bit worse), later. If it is not super-serious (small performance issues, for instance; which can involve moving a lo…

> If it takes a long time to track down, then it should either be sidelined, or the design needs to be revisited.

I don't get this. Either you give up on the bug after a day, or you throw out the entire codebase and start over?

Sure, if the bug is low severity and I don't have a reproduction, I will ignore it. But there are bad bugs that are not understood and can take a lot more than a day to look into, such as by adding telemetry to help track it down.

Yes, it is usually the case that tracking it down is harder than fixing. But there are also cases where the larger system makes some broad assumptions which are not true, and fixing is tricky. It is not usually an option to throw out the entire system and start over each time this happens in a project.

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

#248

Post by dockd »

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…

How is this for a rule of thumb: the time it takes to fix a bug is directly related to the age of the software.

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

#249

Post by x0x0 »

RHSeeger wrote: post #57
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!!

Bugs have priorities associated with them, too. It's reasonable for a new feature to be more important than fixing a lower priority bug. For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it.

I don't think, except for a direct regression, it's even possible to define a bug in a way that isn't the same as a feature request. They're identical: someone wants the software to do X, it doesn't do X, maybe we should make it do X. (Except, again, for it used to do X but now doesn't and that wasn't intentional.)

Treating bugs as different than features and automatically pushing them to the front of the line likely leads to a non-parsimonious expenditure of effort and sets up some nasty fights with other parts of the company which will definitely figure out that something being a "bug" gets it prioritized. Obviously this can be done poorly, and why even have engineers if you aren't listening to their prioritization as well.

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

#250

Post by yujzgzc »

There are really two kinds of "small bugs".

1) Things that have existed in your product for decades and haven't been major strategic issues.

2) Things that arose recently in the wake of launches. This can be because it's hard to fix every corner case, or because of individuals throwing sloppy code over the wall to look like they "ship fast".

I try to hold the team to fix bugs (2) quickly while their memory is fresh as it points to unwanted regressions.

The bugs in (1) are more interesting. It's a bit sad that teams kinda have to "sneak that work in" with fixit weeks. I have known of products large enough to be able to A/B test the effects of a quarter's worth of "small fixes", and finding significant gains in key product metrics. That changed management's attitude with respect to "small fixes" - when you have a ton of them, they can produce meaningful impact worthy of strategic consideration, not just a week of giving the dev team free rein to scratch their itch.

Post reply on HN