Code Reviews in a SCRUM

This is a little different than many of the items I have posted. But I do have four basic passions: Family, Computers, Health, and Personal Growth/Education. Today, I was thinking about SCRUM and how it relates to past software development methodologies. Since I do usually limit these posts to a single major topic, today is SCRUM and Code Reviews.

Too often people think about a Code Review as a tedious, draw-out event that really has no place in a SCRUM. As I study the Agile process, I am realizing that code reviews are agile also and are an important part of a SCRUM. As Jason Cohen points out in Scrum and Code Review — they go together like beans and cornbread, Ken Schwaber and Jeff Sutherland (the co-founders of SCRUM) say that code is not “done” until it is code reviewed. As a side note, I would highly recommend Jalapeno Corn Bread. Making your code reviews a little more enlivened would not be a bad idea also.

In the 1970s and 1980s, structured development was desired. Structured Analysis and Design was developed to overcome the haphazard development methods used before then. Using SA/SD, every stage was very formal and required so many steps that the overhead prevented meaningful work to get done in a short amount of time. Because of this overhead, Agile programming came into favor. How can work be done in a reasonable amount of time? Unfortunately, some people thought that code reviews are part of the overhead. It is interesting that Ken Schwaber and Jeff Sutherland, the developers of the SCRUM methodology, believe that code reviews are a vital part of the process. Code reviews often help find overlooked problems that could cause havoc later. They can also be used for educating new members of a team. Since the same person does not always work on the same piece of code, it is good to have several people aware of many sections of code. Code Reviews also help improve the consistency of code, improving “best practices” in coding and documentation, and increasing good communication within the team.

I like limiting the reviewers to one or two people. In reviewing critical code that affects many members of the team, larger reviews are required. In this case, I would suggest making this review a separate task or story to make sure it is done correctly. The purpose of the code review can vary. If the developers are new to the development environment, the language, or the application, it is good for a more experienced member of the team to review the code to identify common mistakes of newbies, to share algorithms that work well in the desired environment, or help improve the readability and compactness of the code (no, those are not mutually exclusive). If the developer is experienced, the newer member of the team can learn from the experienced developer and ask questions/make suggestions based on knowledge gained outside of the organization. Even more experienced engineers need to continue to learn.

The most common benefit of having a second person look at code is to spot problems that the developer may not see because errors not seen immediately become part of the “background” and are often overlooked until something in that section of the code changes. It is also much less expensive to find problems in the early stages of development instead of when the code is actually released. Remember that the same person does not always work on the same section of code. Having familiarity with different sections of the project helps each member be able to work on more sections and have a better knowledge of the entire product.

Where mutual code reviews are essential are dealing with code interfaces. If one developer has a function that is called by a second developer, they need to verify the calls match, that any “corner case” will not cause a problem, and that all the caller’s needs are handled properly by the called function.

Code reviews are to verify the functionality and help with the maintainability of the code. If coding tasks are kept to an average of one day to complete, code reviews are  a small part of that time and help improve the quality of the final product. To be “Done” a code review must take place.