Up Close

On Code Reviews and Standards

A user group speaker gives development teams simple ways to succeed.

By Jeff Erickson

January/February 2013

It was Martin D’Souza’s code that made the entire project crumble. “I describe it as a Jenga block tower,” he says. “My code was the move that toppled the whole thing.” Under pressure to fix the problem with the applications, D’Souza, who is now an Oracle ACE Director, spent a day asking the question: “How did my team of talented coders get into this mess?”

In analyzing what happened, the team realized that they didn’t really understand the business problem. “Once we spent the time to clearly state the business problem, we realized we could solve it pretty easily,” D’Souza says.

Hours of tedious review also reminded D’Souza that his team members were not on the same page when it came to coding standards. “We were all good coders, but we all had our own styles and weren’t working as a team,” he says.

That project was many years ago, but the answers he found and the simple steps he now takes to avoid similar meltdowns have become the basis of a talk D’Souza delivers to user groups. I caught his talk, “Building a Better Team,” at a recent event held by ODTUG, where he is a board member.

Two Easy Answers

D’Souza recommends two simple practices that can help development teams succeed: code reviews and coding standards.

“Code reviews are the simplest way to reduce bugs,” says D’Souza. “You will find small bugs that might not be caught by your QA team, testing team, or even automated testing software.”

But, says D’Souza, code reviews can have more-extensive benefits for a development team. When a junior developer has to review a senior developer, it’s a learning process for both developers. “ The junior developer can learn from reviewing code with a more experienced person,” says D’Souza. “At the same time, when you’re a senior developer and you have to explain your own work, the lightbulb might go on that your solution isn’t as solid as you thought.”

For this reason, D’Souza recommends that teams keep code reviews as a one-on-one process. He suggests having everyone put his or her name on a Post-it note on a whiteboard. When someone needs to have code reviewed, he or she pulls the top name. “You don’t want the same people looking at each other’s code all the time,” D’Souza says. “And the first question we ask in code review is always “What is the business problem you’re trying to solve?’”

D’Souza also recommends keeping up-to-date coding standards, which provide guidelines for, among other things, how to format code, handle exceptions, and ensure application performance. “Many organizations have code standards,” he says. “But they are often a static, two-page document that was written 5 to 10 years ago.” A system of code reviews that includes a discussion on standards is a simple way to keep the coding standards document a living and helpful resource, he says.

For those who say that enforcing coding standards limits creativity, D’Souza has a simple rebuttal. “My usual response is that it actually enhances creativity because developers are no longer worried about formatting details. They can concentrate on creative ways to solve the business problem.”

Keep It Simple

What keeps organizations from actively pursuing code reviews and coding standards is a fear of the complex methodologies and procedures that often go with them. Better, says D’Souza, to keep it simple.

“I think back to the original meltdown that started me thinking about this,” D’Souza says. “If I had had a simple code review in place, someone would have called me on it. They would have asked me about the business problem, and I would have had to tell them in plain English how I was going to solve it. I wouldn’t have been able to.” He won’t make that mistake again.

Next Steps

 READ Martin D’Souza’s blog

 WATCH the interview


Photography by Clem Onojeghuo, Unsplash