> 1) no bug should take over 2 days

Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done.

That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one.

Also, I tend to attack bugs by priority/severity, as opposed to difficulty.

Some of the most serious bugs are often quite easy to find.

Once I find the cause of a bug, the fix is usually just around the corner.

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.

1. Working on Feature A, stopped by management or by the customer because we need Feature B as soon as possible.

2. Working on Feature B, stopped because there is Emergency C in production due to something that you warned the customer about months ago but there was no time to stop, analyze and fix.

3. Deployed a workaround and created issue D to fix it properly.

4. Postponed issue D because the workaround is deemed to be enough, resumed Feature B.

5. Stopped Feature B again because either Emergency E or new higher priority Feature F. At this point you can't remember what that original Feature A was about and you get a feeling that you're about to forget Feature B too.

6. Working on whatever the new thing is, you are interrupted by Emergency G that happened because that workaround at step 3 was only a workaround, as you correctly assessed, but again, no time to implement the proper fix D so you hack a new workaround.

Maybe add another couple of iterations but at this time every party are angry or at least unhappy of each other party.

You have a feeling that the work of the last two or three months on every single feature has been wasted because you could not deliver any one of them. That means that the customer wasted the money they paid you. Their problem, but it can't be good for their business so your problem too.

The current state of the production system is "buggy and full of workarounds" and it's going to get worse. So you think that the customer would have been wiser to pause and fix all the nastier bugs before starting Feature A. We could have had a system running smoothly, no emergencies, and everybody happier. But no, so one starts thinking that maybe the best course of action is changing company or customer.

(I run a small SaaS product - a micro-SaaS as some call it.)

We’ll stop work on a new feature to fix a newly reported bug, even if it is a minor problem affecting just one person.

Once you have been following a “fix bugs first” approach for a while, the newly discovered bugs tend to be few, and straight forward to reproduce and fix.

This is not necessarily the best approach from a business perspective.

But from the perspective of being proud of what we do, of making high quality software, and treating our customers well, it is a great approach.

Oh, and customers love it when the bug they reported is fixed within hours or days.

The way I learned the trade, and usually worked, is that bug fixing always comes first!

You don't work on new features until the old ones work as they should.

This worked well for the teams I was on. Having a (AFAYK) bug free code base is incredibly useful!!

My preferred approach is to explicitly plan in 'keep the lights on' capacity into the quarter/sprint/etc in much the same way that oncall/incident handling is budgeted for. With the right guidelines, it gives the air cover for an engineer to justify spending the time to fix it right away and builds a culture of constantly making small tweaks.

That said, I totally resonate with the culture aspect - I think I'd just expand the scope of the week-long event to include enhancements and POCs like a quasi hackathon

Also love the humble brag. "I've just closed my 12th bug" and later "12 was maximum number of bugs closed by one person"

    1. Build features at all costs
    2. Eventually a high profile client has a major issue during an event, costing them a ton of goodwill
    3. Leadership pauses everything and the company only works on bugfixes and tech debt for a week or two

I don't mean to be too harsh on the author. They mean well. But I am saddened by the wider context, where a dev posts 'we fix bugs occasionally' and everyone is thrilled, because the idea of ensuring software continues to work well over time is now as alien to software dev as the idea of fair dealing is to used car salesmen.

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Some seem ridiculously obvious today, but weren't standard 25 years ago. Seriously! At the turn of the century, not everyone used a bug database or ticket tracker. Lots of places had complicated builds to production, with error-prone manual steps.

But question five is still relevant today: Do you fix bugs before writing new code?

1) I agree that estimating a bug's complexity upfront is an error prone process. This is exactly why I say in the post that we encourage everyone to "feel out" non trivial issues and if it feels like the scope is expanding too much (after a few hours of investigation), to just pick something else after writing up their findings on the bug.

2) I use the word "bug" to refer to more traditional bugs ("X is wrong in product") but also feature requests ("I wish X feature worked differently"). This is just a companyism that maybe I should have called out in the post!

3) There's definitely a risk the fixit week turns into just "let's wait to fix bugs until that week". This is why our fixits are especially for small bugs which won't be fixed otherwise - it's not a replacement for technical hygiene (i.e. refactoring code, removing dead code, improving abstractions) nor a replacement for fixing big/important issues in a timely manner.

It was by far the most fun, productive, and fulfilling week.

It went on to shape the course of our development strategy when I started my own company. Regularly work on tech debt and actively applaud it when others do it too.

Overall, I think this kind of thing is very positive for the health of building software, and morale to show that it is a priority to actually address these things.

Strangely the math looks such that they could hire nearly 1 FTE engineer that works full time only on "little issues" (40 weeks, given that people have vacations and public holidays and sick time that's a full year's work at 100%), and then the small issues could be addressed immediately, modulo the good vibes created by dedicating the whole group to one cause for one week. Of course nobody would approve that role...

eg: My last company's system was layer after layer built on top of the semi-technical founder's MVP. The total focus on features meant engineers worked solo most of the time and gave them few opportunities to coordinate and standardize. The result was a mess. Logic smeared across every layer, modules or microservices with overlapping responsibilities writing to the same tables and columns. Mass logging all at the error or info level. It was difficult to understand, harder to trace, and nearly every new feature started off with "well first we need to get out of this corner we find ourselves painted into".

When I compare that experience with some other environments I've been in where engineering had more autonomy at the day-to-day level, it's clear to me that this company should have been able to move at least as quickly with half the engineers if they were given the space to coordinate ahead of a new feature and occasionally take the time to refactor things that got spaghettified over time.

1) Things that have existed in your product for decades and haven't been major strategic issues.

2) Things that arose recently in the wake of launches. This can be because it's hard to fix every corner case, or because of individuals throwing sloppy code over the wall to look like they "ship fast".

I try to hold the team to fix bugs (2) quickly while their memory is fresh as it points to unwanted regressions.

The bugs in (1) are more interesting. It's a bit sad that teams kinda have to "sneak that work in" with fixit weeks. I have known of products large enough to be able to A/B test the effects of a quarter's worth of "small fixes", and finding significant gains in key product metrics. That changed management's attitude with respect to "small fixes" - when you have a ton of them, they can produce meaningful impact worthy of strategic consideration, not just a week of giving the dev team free rein to scratch their itch.

I advocate to never size/score bugs. Instead, if your process demands scores, call everything a 2 because over the course of all the bugs, that will be your average. You'll knock out 10 small ones and then get stuck on a big one. Bug-fixing efforts should be more Kanban than Scrum. Prioritize the most important/damaging/whatever ones, do them in order, and keep doing them until they are done or you run out of time.

Fixit weeks is a band aid, and we also tried it. The real fix is being a good boss and trusting your coworkers to do their jobs.

With an average of 4 bugs fixed in 5 days and 150 bugs, we can assume 50 bugs with less than one days's effort were just lying around with noone daring to touch them.

> The benefits of fixits

> For the product: craftsmanship and care

sorry, but this is not care when the priority system is so broken that it requires a full suspension, but only once a quarter

> A hallmark of any good product is attention to detail:

That's precisely the issue, taking 4 years to bring attention to detail, and only outside the main priority system.

Now, don't get me wrong, a fixit is better than nothing and having 4 year bugs turn into 40 year ones, it's just that this is not a testament of craftsmanship/care/attention to detail

I don't mean to sound negative, I think it's a great idea. I do something like this at home from time to time. Just spend a day repairing and fixing things. Everything that has accumulated.

1: https://github.com/google/perfetto/issues/154

It had the same spirit as a hackathon.

[1] https://westwing.fandom.com/wiki/Big_Block_of_Cheese_Day

Having every 3rd or 4th sprint being dev initiatives and bugs... Or having a long/short sprint cycle where short sprints are for bugs mostly... Basically every 3rd week is for meetings and bug work so you get a solid 2 weeks with reduced meetings.

It's hard to convince upper managers of the utility though.

Also explains the casual mention of "estimation" on fixes. A real bug fix is even more hard to estimate than already brittle feature estimates.

What good and bad experiences have people had with software development metrics leaderboards?

I do appreciate though that certain people, often very good detail oriented engineers, find large backlogs incredibly frustrating so I support fix-it weeks even if there isn't clear business ROI.

Doing what you want to do instead of what you should doing (hint: you should be busy making money).

Inability to triage and live with imperfections.

Not prioritizing business and democratizing decision making.