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

271–280 of 356 posts

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

#271

Post by claw-el »

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…

> Also, I tend to attack bugs by priority/severity, as opposed to difficulty.

This is one part that is rarely properly implemented. We have our bug bash days too, but I noticed after the fact that maybe 1/3 of the bugs we solved is on a feature we are thinking of deprecating soon due to low usage.

How can we attack bugs better by priority?

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

#272

Post by DanielHB »

muixoozie wrote: post #198
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 worked for a company that.. Used msql sever a lot and we would run into a heisenbug every few months that would crash our self hosted msql server cluster or it would become unresponsive. I'm not a database person so I'm probably butchering the description here. From our POV progress would stop and require manual intervention (on call). Back and forth went on with MS and our DBAs for YEARS pouring over logs or whate…

I once ran into a bug where our server code would crash only on a specific version of the Linux Kernel under a specific version of the OpenJDK that our client had. At least it would crash at startup but it was some good 2 weeks of troubleshooting because we couldn't change the target environment we were deploying on.

At least it crashed at startup, if it was random it would have been hell.

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

#273

Post by dgunay »

An ex-employer of mine had a regular cycle:

    1. Build features at all costs
    2. Eventually a high profile client has a major issue during an event, costing them a ton of goodwill
    3. Leadership pauses everything and the company only works on bugfixes and tech debt for a week or two
I onboarded during step 3. I should have taken that as a warning that that's how the company operated. If your company doesn't make time for bugfixes and getting out of its own way, that culture is hard to change.

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

#274

Post by Aurornis »

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…

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 upon you and ask why you're dragging the velocity down.

Lesson learned: Next time, avoid the hard bugs and give up early if something isn't going to turn into story points for hidden charts that are viewed by more people than you ever thought.

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

#275

Post by bluGill »

dylan604 wrote: post #261
bluGill wrote: post #225

Earlier quoted context omitted.

I did that once: logging ended up taking 80% of the CPU leaving not enough overhead for everything else the system should do. Now I am more careful to figure out what is worth logging at all, and also to make sure disabled logs are quickly bypassed.

we've gotten into adding verbosity levels in logging where each logged event comes with an assigned level that only makes it to the log if it matches the requested log level. there are times when a full verbose output is just too damn much for day-to-day debugging, but is helpful when debugging the one feature. i used to think options like -vvv or -loglevel panic were just someone being funny, but they do work when n…

On smaller projects that works. We have a complex system where individual logs can get the log level changed. Though this turns out too fine grained. I'm moving to every subsystem being controllable, but not the individual logs. I'm still not sure what the right answer is though - it always seems like there are 10,000 lines of unrelated useless logs to wade through before finding the useful one, but anytime I remove something that turns out to be the needed log for the very next bug report...

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

#276

Post by Aurornis »

mentos wrote: post #196
etamponi wrote: post #145

Ex-Meta employee here. I worked at reality labs, perhaps in other orgs the situation is different. At Meta we did "fix-it weeks", more or less every quarter. At the beginning I was thrilled: leadership that actually cares about fixing bugs! Then reality hit: it's the worst possible decision for code and software quality. Basically this turned into: you are allowed to land all the possible crap you want. Then you have…

Reminds me of ids policy of "As soon as you see a bug, you fix it" "...if you don't fix your bugs your new code will be built on buggy code and ensure an unstable foundation and if you check in buggy code someone else is going to be writing code based on your bad code and well you know you can imagine how wasteful that's going to be" 16:22 of "The Early Days of id Software: Programming Principles" by John Romero (Str…

> Reminds me of ids policy of "As soon as you see a bug, you fix it"

If you'll allow me to project a lot of lived experience on to this story: A policy of fixing bugs immediately sounds like a policy software developers would come up with. A policy of deferring bug fixes to a neatly scheduled week on the calendar for bug fixes sounds like a policy some project managers would brainstorm as a way to keep velocity numbers high and get their tickets closed on schedule.

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

#277

Post by machomaster »

nsingh2 wrote: post #256
machomaster wrote: post #245

Earlier quoted context omitted.

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.

> Be kind. Don't be snarky. Edit out swipes [1] [1] https://news.ycombinator.com/newsguidelines.html

"Please don't post shallow dismissals"

Same source.

Don't trivialize my useful feedback.

If a person tries to communicate, but his stylistic choice of laziness (his own admission!) gets in the way of delivering his message, it is very tangibly useful information to tell, so that the writing effort could be better optimized for effect.

I wasn't even demanding/telling him what to do. I simply shared my observation, but it's up to him to decide if he wants to communicate better. Information and understanding is power.

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

#278

Post by DanielHB »

zelphirkalt wrote: post #127
jaredklewis wrote: post #79

Earlier quoted context omitted.

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.

In my experience frontend bugs are usually from over-complicated business logic with layout-issues a distant second.

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

#279

Post by hiAndrewQuinn »

zeroCalories wrote: post #147
k4rli wrote: post #111

Earlier quoted context omitted.

Imagining that the software will be shipped with hardware, that has no internet access and therefore cumbersome firmware upgrades, might be helpful. Avoiding shipping critical bugs is actually critical so bricking the hardware is undesirable. Example: (aftermarket) car headunit.

This type of testing is incredibly expensive and you'll have a startup run circles around you, assuming a startup could even exist when the YC investment needs to stretch 4x as far for the same product. The real solution is to have individual software developers be licensed and personally liable for the damage their work does. Write horrible bugs? A licencing board will review your work. Make a calculated risk that d…

You don't need formal licensing for this to work, passthrough liability would do plenty. The real sign of success is whether an insurance industry sprouts up to protect software engineers, just like doctors.

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

#280

Post by emodendroket »

etamponi wrote: post #145

Ex-Meta employee here. I worked at reality labs, perhaps in other orgs the situation is different. At Meta we did "fix-it weeks", more or less every quarter. At the beginning I was thrilled: leadership that actually cares about fixing bugs! Then reality hit: it's the worst possible decision for code and software quality. Basically this turned into: you are allowed to land all the possible crap you want. Then you have…

In practice if you really care about fixing bugs/cleaning things up the thing that works best is sneaking that into feature work somehow.
Post reply on HN