At Trevor.io we recently released some fundamental changes to our platform, which, unsurprisingly, came with a handful of bugs. This triggered a debate among the team: which bugs do we fix now? Which do we fix later? And when is later? If we don't fix them now, will we realistically ever fix them?<p>This led us to an interesting question: what if we just split <i>all</i> bugs into "will fix" and "won't fix", and then prioritise every "will fix" above all new features....always. In other words: we commit to only ever adding new features when we're bug free.<p>Has anybody tried this? Can it work?
This is known as a zero bug policy [1]. I've had decent success implementing it with my team. The main advantages are:<p>- Prioritizing is hard, so avoid wasting brain cycles deciding how important your bugs are<p>- It encourages all of your team to get things right the first time, because if they don't they know they will be going back to fix it immediately.<p>- If you want to create a culture of quality then it's an obvious first step.<p>- It saves time in the long term by addressing problems when you have the most context and by avoiding building hack upon hack upon hack<p>In extreme cases you can relax the policy, but be aware that if you don't quickly correct course then things will be permanently worse. Also accept that hard external deadlines are not suited to this approach, but using triage some of that can be mitigated.<p>[1] <a href="https://sookocheff.com/post/process/zero-bug-policy/" rel="nofollow">https://sookocheff.com/post/process/zero-bug-policy/</a>
We did releases that were only bug fixes and maintenance. There can be a long tail of bugs in a complex system, most of which are relatively harmless and only occur in very rare situations; it’s hard to justify fixing these when paying customers are asking for a new feature.<p>Also you’d be surprised at what gets classified as a bug when you apply this.<p>Ultimately though, everybody does this. Critical bugs get fixed first. Anything too far down the backlog de-facto doesn’t get fixed. I like the intellectual honesty that this approach brings, in that it forces you to set a bar for bugs not worth fixing and consequently marking them as won’t fix.<p>Final note: whether a bug is worth fixing changes over time. Maybe your best engineer can’t find it after two weeks. Maybe your biggest customer just ran into it. Maybe you can’t reproduce it. Maybe the platform causing it got acquired by Google.<p>Can it work? Yes, but it doesn’t look very different to what you’re probably already doing in practice.
- New features help close sales.<p>- New features also add tech debt, complexity, cost, bugs, makes you slower, and will lose you some sales that way.<p>- At 0 features you really need to implement features instead of messing about with the bugs in the devops scripts.<p>- At e.g. Windows scale, maybe stop messing about with new features nobody asked for and fix some bugs, yes.<p>- In a Laffer-curve-like effect, there must be a point where it peaks and it's better to fix bugs than to implement a new feature.<p>- It's a very difficult to identify where you are in the curve.<p>- One of the measures is simple "do X, get money from this guy I have on the phone"<p>- The other measure is fuzzy, lags, is subjective, can't be traced to a particular feature.<p>Good luck!
On a sufficiently complex product it is impossible to fix all known bugs, even classified as will fix. Another issue - it will take so much time that your company will be left behind by the competitors. Maybe less so in the web, but with hardware it's a question of multiyear contracts, so getting abandoned by a big customer in favor of a feature rich competitor may mean that you won't get a second chance with them any time soon. Of course a reverse happens too - if your market leading product is more and more buggy over time, they may abandon you or force to fix most bugs, or force to do significant structural changes etc.
Ask yourself: given the system in its current state what change will make my customers most happy? Is it fixing this bug, or is it shipping this new feature?<p>Do the thing that will produce the most customer happiness in the shortest amount of time next.
Morale decline from oscillating priorities.<p>You are bug-free, start working on new feature, new bug reports come in, and you have to pause and work on them.<p>Fixing bugs is not fun work because there is usually a quick fix in an ugly way, and then a perfect fix via a large refactor and re-architecture. This results in that "soul-destorying" feeling of: if I had enough time I could fix this properly in the right way with clean code and avoid huge amounts of bugs, but alas I am just piling on tech debt.
My main concern with the idea is that what counts as a "bug" is sometimes clear, but often subjective. A missing feature can easily masquerade as a bug in some organisations, and the policy you suggest would encourage dressing up missing features as bugs, leading to suboptimal information flows and feedback in the organisation.<p>Effectively, "I think this is important so I will argue you should work on this before that bug" is much better than "I think this is important so I will argue this is a bug."
I have seen this problem solved with a super simple bug classification that anyone can leverage (even customer success) associated with priority and time to fix expectations.<p>YMMV, you have to adapt it to your usecase (B2B / B2C? contractual SLA? ...). But it can be something around:<p><pre><code> - P0 : a bug prevents a significant part of the customers (= paying users) to perform one of the core functionality of the product : at least one dev drops what he is doing right now and investigate, fix it himself or send it to someone responsible for the bug who should drop what he is doing right now and fix it. Target is to have it fixed in under a few hours.
- P1 : a bug prevents a few customers to perform an important yet non core functionality of the product: next dev available have a look at it. Target is to have it fixed in under a few days.
- P2 : a bug customers can live with (concerns few customers / there is a workaround / ... ) -> fixed in best effort, in practice, we fixed them when doing other features near that code. It can take a lot of time to fix them (if we ever fix them, and it's ok. The good thing about tech debt is that it's a debt you don't have to pay, when you remove/replace a feature for instance).</code></pre>
If you're driving users away with some major bugs you better try to fix them ASAP. But chasing "100%" is usually a bad business strategy IMO. When you have an absolutist policy like that you risk losing a lot of momentum over something small that isn't driving much value, just to satisfy the arbitrary policy.<p>Is it worth not making progress on any new features, all because of a smaller bug or issue? Can just one person work on the small bug while the rest of the team starts a new feature?<p>Sometimes the best bug fix is a new feature that depreciates the bug, so be sure to consider the estimated lifetime of the bug if you keep progressing your platform and maybe don't spend too much time fixing things that will be soon phased out anyways, unless they're really major issues that are rapidly hurting the business or reputation and need immediate fixing.<p>If you really want to halt all new features, I might try putting it on a calendar. Maybe you can afford 1 month, 1 quarter, or half a year on just bug fixing but eventually you have to keep moving forward in some way. Unless your platform is already pretty feature complete (which it doesn't sound like it is) you might do more harm than good when delaying your next core feature releases.
Yes you can do it, yes it can work. However as with all things there is nuance. This is a scheduling problem, and just like with a cpu scheduler there are degenerate cases you may need to avoid/handle.<p>Two problem cases likely to pop up.<p>1) Lots of fixing when a bigger refactor is required. A poorly written area of code, or a poor design, may be causing high churn and wasted effort. The solution I’ve found to this problem is to track defects by code area and review once metric exceeds heuristic.<p>2) A team choked on defects only for a long period of time. This obviously has many negative side effects. It tends to happen in <i>really important component</i> and require <i>most experienced developers</i>. Any new starters run for the hills when a team gets into this state, therefore compounding the issues. The solution to this (though this is just my opinion), is to never allow 100% of time over [fixed interval] to be spent on defects. No more than 50%. The bugs will still get fixed, just take longer, and new development is still happening.<p>Overall though, I think a “defects first” approach is the right one, just have a plan for these negative cases.
Assuming these are bugs which have workarounds and don't cause things like data corruption. Then it probably falls into the adage from advertising "50% of all advertising is a waste, you just don't know which 50%".<p>Another way to look at it is the delayed effect of doing nothing in either area. Bugs creeping in over the months and years may only become a problem when a competitor starts to be noticeably more stable.<p>Features that are delayed may have a delayed effect of a competitor getting ahead of you in the market and launching months before you'd be ready.<p>So I would say, "it depends". If you're in a growth market and are trying to capture market share, features might be best before non-critical bugs.<p>If you're in a stable market serving a huge amount of people, then fixing bugs has a much larger impact on your users.<p>You also have to consider the team and their morale over time. Too much churning through low value bugs can be demoralising where individuals might need some type of higher level thinking and creativity.<p>If it were me, I'd look at bugfix only sprints and adjust the frequency based on the above factors.
It would really depend on the severity of the bugs... assign severity levels as part of triaging.<p>Also what kind of bugs are coming up is important... I think bug do tell stories; it might help you identify issues with feature assumptions on workdlow or use-cases and that needs to inform your product development as a feedback loop to avoid technical debt and having to rewrite stuff later.<p>Depending on the size of your team, I would have a 2-4 people focusing on just bugs / QA (so you can catch most bugs going forward) while the rest of the team focuses on new features.
Once you start factoring in reputational damage it becomes easier to choose what/if to fix. If you add new features but the resulting product is something that gives the idea that the platform is unstable or broken you'll end up with people switching to some other provider.<p>If the product has actual customers it makes ALWAYS sense to prioritize fixes along the hot paths. And it you should be easy even for non-technical people to understand. You lose customers.<p>A feature is not done until all major bugs or regressions are fixed.
Adding new features will introduce new bugs in your already "bug fixed" parts.<p>Therefore go for release cycles. Lock features, fix all bugs, then release the version. Repeat for every cycle.<p>You might be forced to release with a few bugs. The conventional procedure is to publicly document the known bugs for each version.<p>If you are fighting fire with bugs, then you don't have stable product yet. Cut off up to a reasonable feature set and fix all bugs when you want to release.
I develop and support DXLab, a suite of interoperating, free (but not open-source) applications for the worldwide amateur radio community; these applications continuously populate databases with realtime information, and interact with many other applications and physical devices (radios, antenna rotators) via serial ports, DDE, UDP, and TCP links. Since the first public release 22 years ago, my policy has been "all reported defects are corrected within 24 hours". Interaction with the user community is direct - via an online group. I typically make public releases bearing new functionality 2-3 times per month.<p>This policy's results have been excellent: users are focused on learning to better exploit the applications and suggesting new functionality rather than complaining about long-deferred defect repairs; even minor, easily worked-around defects create a negative user community mindset that can snowball. The absence of defects increases user confidence, and reduces user-perceived complexity.
Whether this would work depends on the kind of system and the deadlines imposed by external needs of the company.<p>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.<p>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.<p>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.
Your role as a company is to maximize revenue. If presence of bugs makes you lose revenue by customer churning or burned-out developers leaving, fix bugs. If not, create new features. And define a bug as "thing that the customer complained about". If customers don't complain, it's either not a bug, or you are solving a wrong problem.
It's often faster and cheaper to fix bugs right away. It often takes longer to put the bug in a bug tracker and prioritize it than to fix it.<p>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).<p>99% of bugs take less than 4 hours to fix.<p>Bugs slow you down. Keep them at zero! You will be able to finish everything faster!
Microsoft rather famously tried this[1]. And it seemed to really help them.<p>I've worked places that have tried it, too. It does work; in my experience, it literally always improves software quality. But I think it is like how pretty much all diets work, at first, but not over the long term.<p>It becomes unsustainable, as the pressure to work on features grows.<p>Continuing with my diet analogy, I now think of it like bulking and cutting phases. When you are bulking up your product with new muscles (features) you are also adding fat (bugs). At some point the percentage starts growing unhealthy, slowing you down and causing all sorts of ancillary problems.<p>Might be time for a cut phase then.<p>My analogy breaks down (because it's not really a good analogy) with a bigger team. Then you can have people assigned to bug cleanup. But this leads to its own set of problems — do you pay bug cleanup engineers a bunch extra? Because they will tend to be reading Who's Hiring top to bottom after a few weeks of that.<p>I think this does work great, though, when it is for a pre-determined fixed duration of time. (e.g. "3 iterations" or "one quarter").<p>[1]: I think where I read about this is now behind a paywall, but this seems to be the same initiative: <a href="https://sriramk.com/memos/zerodef.pdf" rel="nofollow">https://sriramk.com/memos/zerodef.pdf</a>
How much money are the bugs costing the company vs. how much money (time) it costs to fix them? Classify your bugs on scale of impact on end users, profit loss and other important factors. Depending on the amount and scope of the bugs, one idea is to have a bug fix sprint, I use that term loosely, essentially a time box to work on bugs and make things nicer. When the time box is over get back to feature work.<p>Using libraries and frameworks gets you speed in delivery because you don't have to write that stuff yourself, the downside is there are likely bugs in that software or in how your system interacts with it. No software will be "bug free", striving for that is a fool's errand.
Going to extremes never works like ONLY bug fixes or address tech debt for X time. Or only shipping features even if the foundation is shit.<p>The best option is to accept software is soft and malleable.<p>If it prints money but it’s some legacy code that smells like shit and has bugs, just write a new clean interface on top and build to it. Over time you’ll end up replacing the underlying system while shipping new features and fixing bugs as they pop up. Oh and the money keeps printing.<p>It it doesn’t print money and the code is shit, the project should just be scrapped. Who cares.<p>If people constantly keep building shit code and never improve, just quit because that company probably sucks.<p>Be extreme by being practical.
Great. Now what's a "bug" and what's actually not a bug but some other category of thing so that we don't have to drop whatever else we're doing to fix it?<p>Places with zero bugs policies seem to have much branchier defect taxonomies than everyone else.<p>I've also seen shops just decide to ignore entire classes of problems so that they don't put too many rows in their bug database. So, willful ignorance is another option. I don't recommend it, though.
In a mature product that needs to live long and continuously being developed I just do bug first and features later. I promise that users hate features not working more then features missing. The general idea that we always need to release new features are so misplaced, the best version of Spotify was the original release, the product has not really gotten better with time and more features, the actual reason why 90% use it is just working worse and worse...
This is how I've run my 1-3 man internal corporate line of business development teams for ~20 years. I've always handled bugs first. The biggest side effect I think you'll notice is that you are much more conservative about your architecture and what new features you allow. When everything becomes a potential show-stopper as soon a bug is found, you're much less inclined to try dumb stuff.
> This led us to an interesting question: what if we just split all bugs into "will fix" and "won't fix"...<p>I feel like this already happens in some places, just implicitly rather than explicitly. There's a reason why people sometimes joke about the backlog being the place where lots of low priority things go to be forgotten about, and never be done. The problem with this approach is that even if you <i>could</i> get around to fixing low priority bugs in X months/years, with this approach you would prematurely toss them aside and decide to never fix them.<p>> ...and then prioritise every "will fix" above all new features....always. In other words: we commit to only ever adding new features when we're bug free.<p>This will decrease your ability to ship new features in a timely manner and will put you at a disadvantage if you're up against any sort of competition, that ships "good enough" things soon, versus you shipping "really good" software way later. The benefit of this approach is that it should lead to a more maintainable codebase in the long term, though how much this matters depends on your circumstances.<p>It will mostly depend on how you choose what goes under "will fix" and how much it matches what's necessary to keep the lights on (KTLO).<p>For example:<p><pre><code> - Users can't view a page that's needed for legal compliance, in some popular browsers? Needed for KTLO, fix it, no brainer.
- There are errors when trying to use some niche functionality, which affects around 1-5% of your userbase? Probably should fix it, it depends.
- Some button's logo is offset by a few pixels in a settings page or an info message flashes too quickly after some redirect? Probably nobody cares that much.
</code></pre>
Of course, all of that might also coincide with how you choose to test your software.<p>I once wrote some JWT code to allow multiple systems to integrate and communicate securely. I decided that I wouldn't ship it until I got something like 95% test coverage, enforced by CI and everything. It was doable and helped me discover a few bugs to fix during development, as well as refactor with confidence - but it took something like 4x more time than regular development would, which I can't see working well for the majority of projects out there, outside of core functionality and financial transaction related code.
If you fix all problems before doing anything new, assuming that you (team, customers) can even agree a threshold of seriousness for 'bug', you will ossify. A reckless opposite of never bothering to fix bugs, and just being 'disruptive' for the sake of it, is also unworkable.
I'd love if the industry could have some sort of bugfix-only-month. Just one month per year where everyone goes off to fixing something, and new features are forbidden.<p>In fact, I'd love something like this so much, I'd even be willing to sponsor efforts like that with a bit of cash.
"Does this move the needle most?"<p>There is only so much dry powder. Every hour spent doing something that has lower bang:buck ratio in terms of "moving the needle" is an hour of powder burned. Make those hours count.<p>That said, correctly diving what moves the needle most is startup alchemy.
If my experience suggesting something like this to dev teams is any guide: the world will end, the business will spontaneously implode and burn to the ground, and everyone will die. I have not found a receptive audience for this idea.
It's harder to find new customers than it is to keep existing customers, especially if you have captured a lot of the "market". Fixing bugs to keep existing customers could be cheaper and keep you on a stable financial level.
You should not lose sight of why you have a business, you want to make money. I would suggest, do whatever makes you money in the short AND the long term. Don't worship ideals and chase fantasies.
This is a blunt and unworkable approach. Stopping the shipping of any feature because some bug exists doesn't take what is important into account: the user experience.<p>A more refined approach is to triage the bugs into 4 or 5 levels of severity and then you might reasonably agree that at least all sev1 bugs must be fixed before new functionality is added.<p>Just using a bug triage categorisation of "will fix" or "won't fix" is not granular enough.
A tale of two companies (true story)...<p>I worked for a company a full year that <i>always</i> 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.<p>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.<p>Company #1 - for 5 months of that year, I was the <i>only</i> 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.<p>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 <i>make</i> 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.<p>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.