One of the toughest things I struggled with while transitioning from a larval junior developer to a senior tech lead to a project manager was the fact that (at least in the context of a for-profit business) not all bugs need to be fixed, even the ones you personally think are really really bad. The goal is to make money, not necessarily by producing the most perfect software. The quality bar needs to be high, but there is always a point beyond which the returns for fixing a bug are outweighed by the costs of fixing it: the direct engineering cost, the opportunity cost of not working on a feature, the cost of missing a deadline and not releasing in time for Christmas, the cost associated with the extra risk you’re taking by making a late change, etc. Good places judge all these costs, and the best ones have formal processes for judging lots of bugs at scale and constantly re-evaluate whether a bug should be fixed at this point in the project or not. Sometimes the clear right answer is “no.”
That's fair, but one has to remember that some of the key points are to be balanced, and that, like you said, "the quality bar needs to be high".
And I'm more for prioritizing trying to not introduce bugs than to fix all the old ones. Which is challenging on, how could we call that?, "legacy" software. So that priority can and must be reversed temporarily when that "legacy" is too much.
So it's all very context dependent, and not having anybody (or too few) working on making things better when its needed is not going to deliver any kind of velocity in the long term (and probably the short term velocity is already way too low in those cases). Too bad for the mythical time to market...
So you have to be able to say no to bugfixes, but you certainly also have to be able to say no to the eternal rush of new half-backed features, when needed. A short-term ever obsession on "opportunity cost of not working on a feature" could yield quite paradoxical results if trying to build them on some kind of zombie legacy code (that is only ever edited with disgust and great difficulty, but never seriously refactored).
Not only this balance is hard to achieve, but your role as a senior tech lead and project manager is certainly to consider carefully the cleanup needs, and be an advocate for them when needed, including by pushing back against feature creep pressure. Because if you are not, most of the time nobody else will. As a tech lead, this mean among other things, that a black box approach of parts of the maintained software is out of the question (of course you can delegate, but even then its imperative to stay in the equation for that purpose, only with less details). Paradoxically, even if the quality is crap and the organization notices and tracks loads of bugs, most people will be happy at the moment the bugs are triaged and assigned and eventually "fixed" by more horrible garbage (that is, the impression that something is done), rather than doing the right thing that is to organize a cleanup of the software more in depth.
I've got the impression that it is rare to find projects where this balance is achieved correctly, but maybe it's only because of bad luck. Well in lots of cases, the famous ones (I'm thinking on the level of Linux, Firefox, Python, etc. not just your random niche software) are actually not that bad, and their competitors have a way shorter lifespan when not as balanced...
This is my experience as well. Product progress is prioritized over code quality, and the ultimate cost to velocity is real but often unacknowledged. Bugs go unfixed because they are very hard to fix, and this high cost is taken for granted.
It’s definitely on the technical leadership to stand up for code cleanliness and push back against product, and on the higher-ups to recognize the importance of this dynamic.
One of the toughest things I struggled with while transitioning from a
larval junior developer to a senior tech lead to a project manager was the
fact that (at least in the context of a for-profit business) not all bugs
need to be fixed, even the ones you personally think are really really
bad. The goal is to make money, not necessarily by producing the most
perfect software.
On the other hand, you have to remember the that impact = risk x loss. And developers and managers are notoriously bad at evaluating the risk posed by a bug. It does no good for software to make $10 millon dollars a year for 5 years and then make a $100 millon dollar loss in the sixth, because of a catastrophic bug that no one prioritized fixing because, "It's been 5 years and no one's run into this bug yet."
Totally understand that a project can't be perfect, and I could be wrong, but I feel that if there are a lot of bugs, the project scope is too big and/or the requirements are not well understood.
There is also the matter of really picky customers; however, if a customer can articulate what you are doing wrong, I don't think that it's a bad thing if they are picky.
Quality should be in step with expectations; selling services that can't be achieved with in a specific time slot is worse than trying to fix all of the bugs.
> [...] I feel that if there are a lot of bugs, the project scope is too big and/or the requirements are not well understood.
Indeed. And I'm under the impression that the project's take on fixing issues (not just bugs!) is a central part of that, which goes against OP's argument somewhat:
Scope/requirements are usually not out of whack because nobody thought about it when the project started (that's a whole other world of bad project management). The fact is that we're not good at all at judging how the scope and the requirements will change in the future. When (not if!) that eventually happens, you cannot just go adding random changes and edge cases forever, or you'll end up with a horrible Rube Goldberg machine no one has ever even a chance of understanding. You'll have to consistently monitor the sanity and accuracy of your model and either choose to limit the scope of the thing you're building or to correct the model for those edge cases you haven't considered, lest you monkeypatch yourself into a corner.
Now, those bugs that cost so much to fix are usually those where your model breaks down. And that, in turn, is where it's necessary to regurarly step back, find out which part of the model doesn't fit reality anymore and how you can fix it. Then, you can make one of the two decisions above. I've seen my fair share of code in projects where that wasn't done properly, and sometimes, only ignorance on the management side can explain the lack of panic regarding that code.
> Quality should be in step with expectations; selling services that can't be achieved with in a specific time slot is worse than trying to fix all of the bugs.
I agree, but I think you still need to be deliberate about not fixing bugs. Sure, don't fix it, but create a ticket for it and use it to track how common it actually is.
You also should probably be fixing bugs that "If we're caught out by those third parties before the bugs are fixed, there's a good chance it could sink the whole company"
