[etamponi]

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 one week to "fix all the bugs". Guess what: most of the time we couldn't even fix a single bug because we were drown in tech debt.

[mentos]

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 (Strange Loop 2022) https://www.youtube.com/watch?v=IzqdZAYcwfY&t=982s

[AdamN]

Yeah, Joel Spolsky is adamant about this with the "Bugs First" approach and he claims most of the delays and garbage that Microsoft released during the early years of his career were centered on that one rule being violated.

[Wololooo]

The problem is even if you make a note to fix it later, one you never get back to it and two this drives decisions for things around it, until it breaks...

[AdamN]

It's compounded with multiple teams and ownership. So one team's bugs necessitate another team's workarounds.

[Aurornis]

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

[demaga]

From the post:

> That’s not to say we don’t fix important bugs during regular work; we absolutely do. But fixits recognize that there should be a place for handling the “this is slightly annoying but never quite urgent enough” class of problems.

So in their case, fixit week is mostly about smaller bugs, quality of life improvements and developer experience.

[gregoriol]

It must be part of the normal process. If the normal process leaves things like this to "some other time", one should start by fixing the process.

[IgorPartola]

Say you are working on a banking system. You ship a login form, it is deployed, used by tons of people. Six months later you are mid-sprint on the final leg of a project that will hook your bank into the new FedNow system. There are dozens of departments working together to coordinate deploying this new setup as large amounts of money will be moved through it. You are elbows deep in the context of your part of this and the system cannot go live without it. Twice a day you are getting QA feedback and need to make prompt updates to your code so the work doesn’t stall.

This is when the report comes in that your login form update from six months ago does not work on mobile Opera if you disable JavaScript. The fix isn’t obvious and will require research, potentially many hours or even days of testing and since it is a login form you will need the QA team to test it after you find another developer on your team to do a code review for you.

What exactly would you do in this case? Pull resources from a major project that has the full attention of the C suite to accommodate some tin foil Luddite a few weeks sooner or classify this as lower priority?

[2arrs2ells]

This is a great example... except I think the right answer to "what exactly would you do in this case?" doesn't support your argument.

I'd document that mobile Opera with Javascript disabled is an unsupported config, and ask a team to make a help center doc asking mobile Opera users to enable JS.

[CharlieDigital]

This is too logical, practical, and pragmatic. Which product owner/project manager would approve such a thing!?

Being able to think of simple, practical solutions like this is one of the hardest skills to develop as a team, IMO. Not everything needs to be perfect and not everything needs a product-level fix. Sometimes a "here's the workaround" is good enough and if enough people complain or your metrics show use friction in some journey, then prioritize the fix.

GP's example is so niche that it isn't worth fixing without evidence that the impact is significant.

[IgorPartola]

That is also a solution. But the part where you drop everything to immediately document this, and then involve someone else on the team to write more documentation is the exact constraint I was trying to demonstrate. This bug is out of your and your team’s current context. It is low priority. A workaround reply is appropriate here and may have already been sent to the customer by tech support but it is also entirely appropriate to wait a few weeks to complete even what you stated if it is going to affect the company’s bottom line to do it sooner.

[lkbm]

I just checked and it's fixed now, but for a long time the "Shop Policies" section on Etsy shops had the text of first field misaligned[0]. That's the sort of thing that might get thrown into a fix week, but never actually prioritized outside of a "fix week" situation. (tbf, it also might just get noticed and fixed by an engineer randomly without prioritization.)

[0] See "Shop policies" near the bottom of https://www.etsy.com/shop/ForbiddenGlade vs last December: https://web.archive.org/web/20241215201533/https://www.etsy....

[BurningFrog]

Two thoughts:

- This bug genuinely sounds like low priority.

- This organization seems to operate assuming unforeseen problems will never pop up. That is unwise.

[IgorPartola]

Yes exactly. Any non-critical out of current scope bug must be evaluated for whether it should interrupt the current work. Is it a priority? You cannot automate this process by saying “if is_bug: return {priority: IMMEDIATE}” as suggested by the quote about id above, because you will absolutely destroy any velocity. In fact that quote seems to me to be talking about not committing new code with known bugs, not dropping everything as soon as a non-critical bug is discovered in old code.

Instead you need to have a triage process and a planning process, which to some degree most software teams do. The problem is that most of these processes do not have a rigid way of dealing with really old low priority bugs. A bug fix week is one option for addressing that need.

[BurningFrog]

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.

[tmoertel]

> If the normal process leaves things like this to "some other time", one should start by fixing the process.

Adding regular fixits is how they fix the normal process.

This addition recognizes that most bug fixes do not move the metrics that are used to prioritize work toward business goals. But maintaining software quality, and in particular preventing technical debt from piling up, are essential to any long-running software development process. If quality goes to crap, the project will eventually die. It will bog down under its own weight, and soon no good developer will want to work on it. And then the software project will never again be able to meet business goals.

So: the normal process now includes fixits, dedicated time to focus on fixing things that have no direct contribution to business goals but do, over the long term, determine whether any business goals get met.

[inerte]

I agree completely. Also it gives mental excuse to not fix bugs now and leave it for the upcoming bug fix week. Specially if there's any kind of celebration of what was achieved during bug fix week.

It's also patronizing to the devs. "Internal survey shows devs complain about software quality, let's give them a week every quarter and the other 11 we do whatever we want". What needs to change here is leadership being honest about business, as sometimes fixing bugs is simply not important. Sure sure it depends on the bug... I am talking about when devs complain about having a huge number of bugs in the backlog (most of them low impact) or whatever something that only affects a small percentage. Another strategy here would be to properly surface the impact of said bugs to users / customers... until you do this, nobody has a reason to care.

[sudoit]

My experience at Meta is that those weeks are spent not fixing bugs but working on refactors which increase your LOC and diff count. Many of the tasks engs work on are ones they themselves created months previously as "todos".

I question my life a lot when I'm reviewing code which appears to have been written incorrectly at first so that the author can land a follow up diff with the "fix"

[emodendroket]

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