Why Companies Don't Fix Bugs

Personally I've never found it a problem to just fix things that I see are broken, as a dev, without PM approval, even in very dysfunctional organizations. Sometimes it even goes noticed and people applaud you for it.

In other words: though I acknowledge that the phenomenon described in the article is real, I sometimes feel it's just because developers accept a reality that doesn't need to be accepted.

But fixing a bug requires time from your side (mainly doing the investigation) and from others (code reviews). So if the whole team is working on an “important” epic (this is, one with a deadline, like any other epic) and you come out of the blue with a bugfix unrelated to the epic without telling anyone: well, that’s weird isn’t it? Your EM/PM will ask you why you didn’t prioritise the epic’s tasks, and your colleagues could say that they cannot switch their focus or gather time for reviewing your fix (more so that it’s something that the EM/PM hasn’t approved).

So unless you are overworking (e.g., you work in your jira tasks AND on top of that you fix bugs) I don’t see it.

I would love to work on things that make sense like stabilising the system and all, but I work on whatever sells or whatever the EM/PM wants. These days unfortunately, shipping >>> fixing.

In my (albeit limited) experience, there's slack in the workweek, and that slack can provide the required time to do random stuff.

I recognize this isn't true in organizations where everything is micromanaged, work time is tracked in hours or even minutes, and autonomy doesn't exist.

The more the employees are treated like responsible professionals, the more this is possible. And conversely, the more they're like factory workers behind a conveyor belt, the less this is possible.

If you're temporarily in a "let's ship before the deadline" mode, sure.

And if you're _always_ in deadline mode, I'd argue you have a bigger problem.

1. Code the fix while you're sitting on some pointless video call.

2. Merge the resulting fix in as part of another MR

3. In the unlikely event anyone questions you, say that you needed to make changes in that area anyway, and it'll reduce the support burden.

This requires a lot of passion and motivation from individual developers within the company. Of all things they could be slacking off with during a pointless video call, they have to choose to spend than time doing thankless bug fixing.

Depends on the company.

I've worked in places where I was forbidden to fix bugs. Even if it was 1 line adjacent to the code I was editing.

The boss there used to work at amazon. I guess it wasn't a simple coincidence.

It's also not true in organizations where headcount has been pared back to the very bones, so that everything is crunch time, all the time.

I'm not working overtime to fix bugs that management has decided that can't be arsed to prioritize.

also known as Agile™ approach

It is still rare for a company to explicitly decide to devalue quality and mid/long term costs, and typically it is a side effect of incentives.

Obviously 'fake Agile' is an industry wide problem here. But if teams cannot control their capacity expectations, it will always devolve to this

'slack' was a poor term to use IMHO, but it is here.

In companies that care about med/long term survival and success can fix this over time.

Selling it as derisking on strategic and initiative time scales is one way that can help.

This is a good way to introduce regressions, particularly if you don't have the QA resources to do full regression testing each release and lack automated test coverage.

I don't say this to scold you, but I think most of us should keep in mind that even simple code changes incur risk and add testing requirements.

It's extremely dysfunctional to micromanage devs to the extent that they can't take a bit of time to fix a bug without getting permission from someone. Unfortunately, a majority of companies in the industry are extremely dysfunctional.

What about QA, code review, documentation,...?

Ive repeatedly gotten at a trouble at a job, for fixing even minor things - like moving a loop around or factoring out a single function, without PM approval. Cause it takes time from the team to review instead of working on their own things.

There is only slack for places that allow it. All too many companies overpack their sprints with as much as possible.

> In my (albeit limited) experience, there's slack in the workweek, and that slack can provide the required time to do random stuff.

How do you incentivise developers to put that slack to good use? In my experience, without an incentive, culture slowly rots to the point where the majority of developers simply don't.

>Personally I've never found it a problem to just fix things that I see are broken, as a dev, without PM approval, even in very dysfunctional organizations. Sometimes it even goes noticed and people applaud you for it.

It's a lot easier when you're not shoving out a release every 2 weeks. When I worked at a company with quarterly releases, the standing order was fix any bug you see and we saw drastic improvements after just a few releases.

And yet it's called a "Sprint"

> What about QA, code review, documentation,...?

We are Agile now. Continous "improuvment". /s