Ask HN: What would happen if we prioritised all bugs over all new features?

Joel worked on Office. Have you heard the hair-on-fire customer stories about Office from the 90s? It was a draconian response to what was probably seen as a serious company-wide problem at the time.

Does your system have a lot of (intentional or unintentional) emergent behavior, like a sandbox-heavy video game? You could end up never making a feature again.

Do your customers expect the frequent shipping of new features? Unless you can sell them on the idea of unexpected or infrequent addition of features, you could quickly lose your core audience.

However, if it is a product that no one is expecting tight deadlines on the release of new features, or the product's purpose is straightforward enough that there is no intentional emergent behavior in the system, then I could see someone running it in this way. I don't mean this in a cheeky way: there are definitely products that fit this criteria. It just won't be something that every product can reasonably do while also expecting to retain their user base.

I worked for a company a full year that always prioritized new features over bug fixes, or even QA. This was a sales-driven company. For various reasons, it was a toxic environment and I left.

The next company I worked for prioritized good engineering over shipping a product. This was an engineering-oriented company. It's funding was running low ('cause - well, no product!) and I got caught up in a layoff.

Company #1 - for 5 months of that year, I was the only QA person (with 13 devs). Literally no time to automate regression - there was always the "next feature we need to close a sale to customer 'X'". I told my boss that inevitably I (or my occasional comrades) would miss something and the company would be liable. Sure enough, within 18 months of my exit, they were hit with 3 different lawsuits.

Company #2 - absolutely delightful environment, except for the non-technical CEO. Understandably, he wanted to return value to the investors, but he kept making short-term decisions about direction that, while intending to make money, ended up accelerating the cash burn. I was promoted to be a technical lead of about 8 people on a side-project that was supposed to leverage technology from a company whose name is a homophone of 1 × 10¹⁰⁰. No surprise, mega-company changed the rules and our potential product was DOA. The entire team (including me) was let go.

TL;DR - quality is engineered in, and everyone owns quality. If a genuine defect exists, determine its severity and likelihood of emergence with customers to determine priority. Don't ship/push to production any code that will cause customers to lose data or their ability to run their businesses. If you have to make a choice, choose bug fixes over new features.

I have a simple rule that has worked to keep bugs at zero. If you find a bug, drop what you are doing and fix it. If it takes more than 4 hours, only then, put it in your backlog and prioritize it like everything else. Don't keep a separate bug list! Bugs should be in your backlog if they are serious enough (more than 4 hours to fix).

99% of bugs take less than 4 hours to fix.

Bugs slow you down. Keep them at zero! You will be able to finish everything faster!