That Small Fix Isn’t So Small

Having worked on many projects both internal and part of open source I’ve seen a lot of cases where so-called “small changes” turn catastrophic. For those in management who may not have a lot of technical background the time required for the fix can seem frustrating. Even so the processes that introduce these time constraints are not to be taken lightly. Each of them provides a considerable benefit to customer satisfaction and risk management.

This article will look at the processes involved to better understand what’s happening under the hood. Standard business processes will be used to promote understanding of what these technical processes entail for more non-technical types. At the end of each section recommendations will be provided for management to empower their employees with the right tools. For the more technical types I’ll use a docker issue I worked on recently to provide a real world use case.

Reproduction

The first natural step to take when introduced to a bug is reproducing it. In many cases this can be the most time consuming part of the task. It is also meant to consider a number of business facing factors including:

• User environment stability: If a user’s issue is caused by a bad environment, it’s imperative to get them a working one so they are able to perform their job properly.
• Risk management: Understanding the context of what causes a bug lets developer test against it later and reduces the risk that the same issue pops up when…