Ensuring that defects have a Change List and Change Lists have reasons / defects added

There are some processes that are pretty important for software development teams to follow in terms of being track changes and the reasons for the same. What kind of changes do you track ? Well, here is an example (and this post is meant as an example, teams should review what are the kind of items they are tracking and why they would want to track these changes). In this post, I talk about ensuring that all code changes have a mention of the reasons why the code was changed, as well as whenever a defect has been marked fixed, then the defect management software would have a note on the code change list. Why would you want to track changes ?
- It provides some discipline for the development engineer. The knowledge that each change needs to have a reason for the same ensures that the person thinks in more detail about the change.
- The reason for the change ensures that somebody else who is reviewing the change can easily pick up on what the changes were. For example, if there is somebody who is doing code review, then it becomes easy to identify the reason for the change and do the due diligence about the impact. When there is a code change due to a defect, then reviewer can read the defect and even determine whether the code change will really fix the defect or not.
- The tester can look at the Change list mentioned in the defect, and use this to determine whether the change list has been made it to the current build or not. This helps save time, else the other way would be to test for the change and then determine whether the defect fixing change has made it to the build or not, which would take more time.
- The person who made the code change may not be with the group or the organization at a later point of time, and somebody who takes over the code would find to easier to determine the reason why code changes were made by reading the notes and thus determining the reason.
- Searching for a specific item in the code base or the defect management software would become much easier. For example, if the team wanted to find out the exact code change that was done for a particular defect, they could easily do so with this information present in the database and then finding the particular section of code.
- During periods when the team is under lockdown and only controlled changes are made, these changes need to be approved by a different set of people, typically managers and/or leads. They would look at the code base and see the Changelists that have been approved, and then review the defects for which these changes have been made, and then review the actual defect before making a decision on whether the changelist was appropriate or not to be approved. Doing these kind of workflows would be much more difficult if the relevant data was not added to the various tracking systems.

Ensuring that you have knowledge of changes in components that you integrate ..

Most modern day software applications use a number of components within them. The advantage of using components is that these components can get a lot of specialized functionality implemented through them, which would otherwise be difficult and hard to implement if the application development team wanted to write all this functionality. And even if the team was able to do all this, just maintaining all these specialized features can be a big problem. Consider the case of a software which needs to create a video that needs to be burnt onto media such as CD/DVD/Blu-Ray. Now, all of these are specialized features that are done pretty well by many components, both open source and commercial. However, if the product team wanted to write all this functionality as a part of their product, they would need to also make sure that they are maintaining all this code. Even for this specialized job, there are a lot of maintenance that needs to be done. The code for this area needs to be work on any new optical media that is introduced, such as when Blu-Ray's were introduced, and when new versions of Operating Systems for both Windows and Mac emerge, the features should work as well. For all this, it is a better strategy to ensure that components are used for specialized functionality.
However, there are some risks that come out when using components, and these risks can exist whether the component is from another group within the organization or from an external organization. One of the biggest risks is when the component is being used by multiple software applications, and your application does not have dedicated use of the component. In such cases, there is a need to be somewhat more informed about what the changes are that are happening in the component. Even if consider the above case about a component that allows writing to a DVD, another product that may be using the component may request for a change in the component for some need of theirs. And the component makers may decide that such a need is genuine and put in the required feature.
There is an even chance that the new feature that has been put in may not impact your application, but there is still a chance that it may have an impact on your feature workflow. For example, you may be using the component in a silent mode, whereby no dialog from the component may show up, but another organization requests a dialog to show up for a need of theirs. In such a case, you would need to ensure that you know about this, and the discussions with the component makers would need to ensure that there would be a way of ensuring that such a new dialog does not pop up in your workflow, such as a parameter that could be passed from your application code to the component which ensures that the new dialog does not pop up.
In all such cases, even though it is the duty of the component maker to have a list of changes in the component from the previous version, it is also your duty to check that none of the changes impact your application. And if you are integrating an open source component, you may not have the ability to get the external team to make any changes to their application, so you need to very carefully check their changelist and see the impact this has made on your application. Only if there is no impact should you incorporate a new version of the component in your application.
This is one of the risks of your project planning and depending on the number of components you use and the profile of those components, can be a high level of risk that needs to be checked at a regular interval.