Equation 2: Increase Code Knowledge

The speed at which a developer writes code has nothing to do with how fast the developer types. It’s all about how well he understands the code that he is asked to modify. When a developer is assigned a task, he needs to understand what the existing code is doing, how to change what it’s doing, and be able to foresee the impact of his changes. This requires code knowledge. Thus, expanding each developer’s code knowledge will broaden the range of tasks that you can assign each developer, as well as reduce the time required to complete each task. How do you achieve this?

One way is through peer code review. When one developer reviews another’s code, he learns about code complexities and connections. This ends up expanding the amount of code that each developer can work on, and the speed at which tasks are completed. In addition to expanding the knowledge of the reviewers, this process also provides additional insight to the reviewee, who receives valuable team member feedback on how the code he wrote relates to the code base as a whole. To learn more about how to optimize your peer code review process, see Peer Code Review Best Practices.

Another way to increase code knowledge is through regression testing. If a developer is not familiar with the code and has to change it, his greatest concern is probably breaking something that’s already working. Regression test suites instantly alert developers to any unexpected impacts—for instance, if a modification changes or breaks some existing functionality in another part of the application. In addition to teaching developers them about correlations between the modified code and the other parts of the code base, this also increases productivity by giving developers the courage to improve and extend code without being stunted by fear.

Expanding each developer’s code knowledge also promotes productivity by preventing mistakes that lead to debugging and rework, which are discussed in the next two equations. The less familiar developers are with the code, the more prone they are to make mistakes that will slow productivity long after the implemented piece of code is first checked in.