How do we know this version of source code is what we think it is?
Developers are optimists. Formally managing source code changes at the beginning of a project sometimes feels like an extra burden. But skipping this step at the start of a project only delays cost (a so-called “technical debt”) until later in development.
Figuring out which system components to change when requirements change
Re-doing an implementation because we modified code according to changed requirements but did not communicate that to other team members
Losing productivity when we replace a component with a faulty new version and can’t quickly revert to a working state
Replacing the wrong component because we couldn’t accurately determine which component needed replacing