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.
- 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.
