We Committed to a Zero-Bugs Policy
Posted3 months agoActive3 months ago
linear.appTechstory
calmpositive
Debate
20/100
Software DevelopmentBug TrackingProductivity
Key topics
Software Development
Bug Tracking
Productivity
Linear's 'zero-bugs policy' aims to eliminate bugs in their development process, sparking discussion on the feasibility and implications of such an approach.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
18m
Peak period
4
0-1h
Avg / period
4
Key moments
- 01Story posted
Sep 26, 2025 at 2:42 PM EDT
3 months ago
Step 01 - 02First comment
Sep 26, 2025 at 3:00 PM EDT
18m after posting
Step 02 - 03Peak activity
4 comments in 0-1h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 26, 2025 at 3:19 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45389703Type: storyLast synced: 11/17/2025, 1:17:05 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Aside from that, while it might seem like an ideal engineering culture, I find it a bit extreme. The harsh SLA leaves little room for prioritization. Sometime the team is in fact working on a tough integration deadline, and medium-level bugs can wait for it to finish.
Going over my current list of bugs, some are minor and can wait to the last mile of the release and some will be resolved by new features we have in planning. I do aim to minimize the list of bugs and even my email inbox is based on a "zero inbox" policy. Still "zero" in this case is some small epsilon that is under control, and will go down to zero if no new bugs/emails arrive in the meantime. Call it a sliding window of epsilon width, but it almost never really reaches zero.
Isn't this policy overruling the judgement of the team/product lead and focuses too much "only" on the bugs?
> The zero-bug stance means that we address bugs immediately
That's the key part. What does it mean "address"? I worked in organizations, where a dev could push any fix to dev basically anytime. CI pipeline would get the fix deployed in 3 minutes and it's there. However, getting that fix to production and to the end user was a completely different story. It required hours or even days of concentrated effort in managing all the communication. Justifying an out-of-process deploy was painful enough. So most people wouldn't do it, the bug will be fixed in the next quarterly release anyway, and my paycheck is the same, so why bother?