Focus More on Code-Review Worthiness of the Code for Better Code Reviews

Photo by NESA by Makers on Unsplash

Have you ever been in a situation when you were asked to review a project’s code with almost no governing rules or principles? Sparks fly, hearts break, and justifications are shot at you like bullets. You risk creating a low-intensity melodrama. As an outsider, even when you are courteous, polite and show understanding, you cannot conduct a code review without causing some level of resentment, and yes — suggesting some dreadful code rewrites. At one end you have managers and stakeholders getting excited about how the product will scale newer heights, and at the other end you have the code that does not let the product evolve.

Most likely, your suggestions will never get implemented because:

1. It challenges the fundamental premise on which they built the code and will take non-billable time-consuming efforts to re-factor it according to your rules.
2. The team is in no mood to agree with you because their intellect was challenged.

For a successful and meaningful code review, firstly a Reviewer needs to earn his/her place as a Reviewer, and more importantly, the developer’s code needs to earn its Code-Review Worthiness. Without these two things, the review becomes a fruitless exercise that does not improve the quality of the code.

Code review only happens when the code meets a certain condition of Code-Review worthiness. Without this initial condition, the code review calls for major changes in the code's structure and becomes a time-consuming affair. If you cannot review the code in 1/20 th of the time in which the developer wrote it, then it becomes a ceremony that has no place in the project.

I have a very simple rule: After glancing the code just for 30 Seconds, if I don’t understand the business intent of the code, I don’t review it unless the code is re-written to make the intent clear.

What you need is not elaborate coding standards but a Code Quality-Level Agreement.

Code Quality-Level Agreement (CQLA)

This is just a short document on the expectations from the code before it can be considered for a review and the reason for each expectation. It should give the project a good start.

The document should not talk about any technology or have any code examples. It should be open to change and evolve with time and maturity of the team or software engineering discipline. It should majorly carry rules for code organization. It can have references to books or other documents, but not too many.

It must have a maximum of 3 pre-condition levels at which the code can be rejected for reviews.

Each point should cover only a narrow territory and the length of the document should be strictly limited to a length where it is humanly possible to recall each point from memory.

Advantages of Code Quality-Level Agreement

Sets a Bar That Can be Raised

Code reviews can feel like getting stuck in a time loop with the same issues reappearing again and again. As the project progresses and the team becomes more and more mature, the bar for Core-Review worthiness can be set higher by expanding or editing the CQLA. You will not be stuck stuck with menial things in the code and focus will shift more and more towards quality at a higher level and raise the level of thinking of the team.

Teams will stop thinking in terms of technology and more about code organization.

Makes the Process Anti-fragile

Mistake we make is thinking the rules we make for a team or project will also work for other teams and projects. CQLA makes the process of code review adaptive. It learns from the team’s mistakes and dynamics. It becomes stronger with each cycle.

Gives Meaning to Code Reviews

For Code Reviews to be meaningful, the context needs to be set at the beginning. Without the context in place, code reviews are like parachuting into a war zone.

Developers are very protective about their code and defend it. CQLA won’t bring down walls, but at least it will help you and the developers to build bridges across each other's walls.

Reduces the time required for reviews

Software companies struggle hard to negotiate time for development. Blocking large amounts of valuable time for just reviewing the code becomes a practical impossibility.

If the code cannot be reviewed in 1/20 th of the time in which it was written, then it becomes a ceremony that has no place in the project.

With the code-review worthiness test, you can have multiple reference points to stop the review until corrective actions are taken.

You Grow as a Reviewer with the Team and the Project

With every code review, you will learn something new from the developer’s code and good ideas can be adopted throughout the project. With every good idea that you adopt and every good suggestion you give, you will gain the respect of your team.

CQLA adds gives a sense of participation to the team. It makes them feel that they are partners in building the process.

CQLA Guidelines: Expect them to be Flouted

What do you do when a developer repeatedly flouts a rule? Find the reason behind it. Most probably, the developer understands the rule but cannot apply it in real time situations. Stop the review, explain the rule again and the reason why it should be followed, and ask the developer to check for such instances and get back with improved code.

Keep a per week rejection count. That which cannot be measured cannot be improved. Part of responsibility for each rejection also falls on the reviewer.

Growth Through Rejections

Developers are not new to rejections, and we know they hurt. But at the same time we all know that rejections also help us grow and become better. With every code review rejection, the developers will become better at writing code. It will also help the team develop a mindset where writing good code will become effortless and second nature.

Conclusion

Code reviews must be designed for a long-term purpose of growth. We must look at code review not as a stagnant activity, but as something that will help increase the coding and reviewing abilities of the team over time. Code reviews should facilitate the team to understand that the code is written for people and not computers. With every Code-Review worthiness bar raised, newer things that need attention will surface and can be focussed on.