Let's say you have a rather old project (about fifteen years old), and a few developers working on it.
Today, there are no special practices regarding code quality, at least the bare minimum (code review and PR are still in their infancy, no CI/CD etc.).
This creates technical debt on the one hand, and bugs on the other - in short, a whole host of things that your developers will have to work on rather than features.
If you're the technical director or project manager on this project, at what point do you say to yourself "wow, this is serious, it's becoming the top priority"?
Now let's say I've analyzed the last 1500 commits and 45% of them contain the word "fix" or "bug" or something like that.
Mind you, we're also talking about fixes that haven't been reported by users, some of which are proactive (but still went to prod).
Is this normal in some teams? Let's face it, even in companies with extraordinary code quality, we never reach 0% of commits to fix WHAT HAS REACHED PROD (important). I'd really like to know at what point you say to yourself "we've got a code quality problem and we've got to deal with it NOW".
What metrics do you use to monitor the quality of your code? The % of commits containing "fix" or "bug" well... that's a start but I'd like more tangible things.
You can guess my side and how it is important to me but... how to convince my boss ? Obviously answer like "as long as there is one bug per year it's the top priority of the whole team to increase code quality", well it won't help, let's stay in real world with real issues :p)
Top comments (0)