A team’s productivity sometimes comes down to small details that may seem insignificant on their own but make a big difference when combined. The Programmer’s Black Book discusses at length how to eliminate bad habits and adopt good ones in order to improve productivity. Sometimes productivity is understood solely as working more hours. I believe working productively has more to do with using tools correctly, having a well-organized team, and following good procedures.
One procedure that can save a great deal of wasted effort is correctly submitting the latest changes to the code repository. As is often the case, the best habits and techniques are also the simplest.
How much time have we spent resolving conflicts in code introduced at the same time as, or after, our latest changes? Too much, considering that this time is unproductive and sometimes frustrating.
The following technique aims to minimize the possibility of conflicts. The more developers there are on a team, the greater the likelihood of these problems.
To reduce the chances of code conflicts when introducing a new change:
- Get the latest version (this ensures we never work with obsolete code).
- Make the changes or add the new functionality.
- Run all the tests; 100% of them should pass.
- Get the latest version again. This lets us see whether our changes introduced any build errors alongside changes made by others (or vice versa).
- Before submitting, run all the tests again.
- Only then submit the changes.
This drastically reduces the possibility of conflicts.
There are different opinions about how often to submit changes (every X hours, when a feature is completely finished, and so on). It depends on the nature of each project. Personally, I prefer submitting frequently (several times a day).
It’s best for the team to agree on the procedure to follow for this process (the check-in process): one process—even if it isn’t the best—is better than none!