We stopped roadmap work for a week and fixed bugs

Fixit weeks: value and potential anti‑pattern

• Many commenters like focused “fixit”/“bug bash” weeks: they’re fun, boost morale, foster camaraderie, and let people finally tackle small, long‑standing annoyances and tech debt.
• Others see them as a band‑aid or even anti‑pattern if they substitute for ongoing technical hygiene. At some companies, “fixit weeks” became an excuse to ship sloppy code fast and “clean up later,” which never really happened.
• There’s concern that having a scheduled fixit encourages deferring easy fixes: “we’ll do it in fixit week” instead of addressing them when first noticed.

Bugs vs features and prioritization

• Several argue that a buggy feature is simply an incomplete feature; bugs should be treated like any other work and often “fixed first.”
• Others emphasize business reality: organizations optimize for revenue, not completeness. Non‑critical bugs, low‑usage paths, cosmetic issues, or niche configurations routinely lose to new features.
• Multiple comments highlight the “death by a thousand cuts”: individually low‑priority bugs aggregate into a noticeably poor product, potentially causing a step‑change from “good enough” to “crap.”

The “2‑day bug” rule and estimation

• The post’s “no bug should take over 2 days” provoked heavy debate.
• Many say you can’t meaningfully estimate bug‑fix time a priori; hardest part is often reproducing and understanding the issue.
• Numerous anecdotes describe bugs that took weeks or months: race conditions, intermittent hardware/compiler/db issues, misdocumented chips, memory corruption, cross‑system interactions.
• Defenders point out the article’s intent: it’s a hard timebox during fixit week—if a bug balloons, document findings, push it back to the backlog, and switch—so the week stays fast‑moving and rewarding.

Process, culture, and autonomy

• Some teams practice “bugs first” or “zero defects” as normal mode: bugs are fixed before new work, leading to relatively clean codebases and few surprises.
• Others describe environments where bugs only get addressed after customer pain or outages; leadership focuses on features, velocity charts, and story points, discouraging deep or difficult debugging.
• A recurring theme: giving engineers autonomy (and explicit capacity) to fix bugs and refactor continually tends to reduce headcount needs and long‑term friction, versus centralizing “quality” into rare fixits.

Definitions, metrics, and incentives

• The thread notes that the fixit covered both classic bugs and small features/polish items; what’s labeled a “bug” can be fluid and political in “bugs first” cultures.
• Individual bug leaderboards and metrics are viewed as dangerous in normal operation (easy to game, skew behavior), but seen as harmless or fun for short, team‑based events.
• Several people prefer explicit, ongoing “keep the lights on” capacity each sprint over episodic bug weeks, but acknowledge that events like fixits or “cool‑downs” are often the only thing leadership will approve.