We have a fully automated deploy process but as we now sometimes we break things.

When this happens the developer just apply a hot fix in (branch, fix and opens a PR) the trunk development. As you could imagine in this situation we lost the bug incidence metric.

So at the moment we are not capable of see if we are fixing too many bugs instead of delivering new features.

What is a good practice to avoid loosing bug incidence tracking? One of the options is to link Jira (Issue tracking tool) with Git hub. So to deploy software to production we must have a opened ticket on Jira.

So how do u guys manage those kind of metrics? Do u just rely on process and advocate users to create bug/issues?

  • 2
    You're asking "if we are fixing too many bugs instead of delivering new features", but you don't explain what that means to you or why it's a problem. Metrics for their own sake are worthless. What's the actual business problem you're trying to solve?
    – Todd A. Jacobs
    May 3, 2018 at 4:27

3 Answers 3


To me the answer is one word: transparency.
But there's a lot more behind this. It's about creating an atmosphere where team members don't feel embarrased when a bug pops up. And I don't know about the situation in your team. But often there's some naming and blaming involved. In my experience, managing to avoid this and to create some trust and openess will lead to more transparency and this will bring your developers to follow the guidelines self-motivated. And then you won't have big issues with incident metrics.

If the company culture is not so open (I'm facing this pretty often), it helps to stress the necessity of metrics. In the end it helps the developers to see where they are standing. And it is a lot about controlling. It is not pleasant but helpful.

  • 1
    The point is that we can not manage what we don't measure. We are so open and light weight process that the developers don't think it's necessary to open a ticket and then correct the bug. They just correct the bug. But without measure bug incidence we can't understand the root causes and evolve our development process. May 3, 2018 at 3:59
  • @p.magalhaes Is this comment for me or for Todd A. Jacobs? May 3, 2018 at 5:26

The good practice is change management, four-eyes check and segregation of duty concepts.

If the change is being delivered to production it should be classified (e.g. Regular Release, Hot-Fix, etc.). There should be the role that makes sure there is a proper track that each release type leaves. For example a hot-fix should be initiated by an incident, have the proper defect raised including the properties like "Detected in phase" or "Is prod issue", etc. Having all those things the role gives a sign-off for deployment.

There should also be some technical harness for supporting the process like hooks in VCS, and orivilege management systems like Power Broker that will minimize the risk of unauthorized actions. Having Reviewer role will also make sense to audit the process from the beginning to the end.



If you want to release fewer potential bugs, redefine your development, testing, and deployment pipelines to provide comprehensive test coverage and integration testing. That's largely an engineering matter, though. The real answer to your posted question is for the business to do a better job of capturing the impact of bugs discovered in production, and then identifying process controls that mitigate the impact.

Measure Defect Impact

One way to measure defects is to capture their effects, and to sum the attendant costs associated with those effects. In other words, bugs that cause problems in production can be toted up by tracking the number of problems users experience in production, by how much time or money it costs to remediate them, or some other measure of actual business impact. A "bug" that doesn't destroy data, bothers no one, and largely goes unnoticed would make it hard to justify a heavy-weight process to prevent or track it.

In your case, there is certainly an implicit problem, but it's not primarily in the way that bugs are making their way into production or the lack of metrics around how they're patched. The core gap appears to be that the business is neither monitoring its production infrastructure, nor tracking customer/user issues. Without tracking the effects that might then be tied back to the development or maintenance process, any purely development-based metrics you devise are essentially worthless from a business point of view.

Business & User Repsonsibilities

In comments, you mention that you think it's the developers' responsibility to track bugs. Aside from the fact that modern source code management systems are certainly able to report when patches are applied, and to differentiate between development and maintenance branches when tags, branches, or other useful engineering practices are consistently applied, ultimately the sources for identifying "unprevented" bugs are:

  1. system monitoring
  2. user-generated problem reports
  3. post-mortem log/dump analysis

It is the responsibility of the business to ensure that adequate resources are expended on monitoring, ticketing, log aggregation, and so forth. It is also the business' responsibility to allocate resources for developing more mature development practices that can avoid certain classes of defect, but that will never guarantee a complete lack of bugs.

Users also share some responsibility. If a user experiences a bug, the user should open a bug within whatever tracking system you use. If bug tracking isn't important enough to bother users about, why would you imagine it's important for the developers?

The implicit bias in your question is that the developers are responsible for both the lack of rigor in your process and at fault for releasing buggy code. It would be more accurate to say that the entire business process shares ownership of the bugs and lack of tracking metrics. You need to ensure that management and users participate appropriately in crafting whatever processes and controls may be missing, because a great deal of the responsibility is theirs, too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.