What are the pros and cons of design/code reviews?

Question

Design reviews pre-implementation I am assuming ensures a good design the better meets the requirements of a project. Code reviews during implementation ensure that the coder properly translates the design into actual code. Are design reviews necessary? Pros and cons.

Answer 1

Design reviews are critical. If developers just get handed a design they feel they had no input to they will probably be less likely to stick to it during implementation.

Answer 2

The best about design/code reviews: it makes you think about your design.
When you know you need to explain your design or code to someone, you (probably) will take more care when writing it.

And of course, the reviewer might even have good ideas and feedback about your design/code to share.

Code reviews are a good way to bring new developers up to speed faster: If you point out potential problems and better solutions to someone in his own code (in a friendly way, of course), he will learn better coding style much faster. Of course you'd have to make sure to explain what the differences to the better code are. Just "I like it better that way" does not cut it.

I'm starting to love code reviews myself - I'm in a senior programming position and am changing more into the role of helping other programmers to solve hard problems, make code reviews, instead of programming (OMG I'm turning into a manager).

As the person reviewing the others code, always try to learn something from them! There always is something to learn, even from our 7-day-school-intern who programmed some small php stuff I learned interesting ways to do stuff.

Answer 3

Pros - Design and code reviews also help to ensure consistency amongst a team, especially when dealing with junior programmers or when moving into new technologies or methods of programming. (my team went to MVP, but all the developers implemented it in different ways. reviews were needed to help get us all on the same page)

Cons - if not done right they are a whipping. Some developers use them to beat up on anyone who does not agree with them. Other times they become a line by line discussion of the code instead of over-arching architecture discussion. Or they become a formality that is just drudge work.

Answer 4

It depends on the team size, skill levels of the team members and how well they know each other. Small team that has high skill level and have been working together for a long time, would not need this and it may waste time. In this case they can resolve design and coding issues "on-the-fly" through immediate interaction and not wait for a meeting.

It will also make for better continuity and no stop-starts.

Answer 5

Reviews of perfect code and design add little value, but they also take very little time, so there's little to lose in trying them.

In addition, design and code reviews can help you share knowledge with the rest of the code team. It makes code ownership more global than individual, which means that somebody can take over your tasks if you get hit by a bus on your way to work or change jobs.

Answer 6

I'm of the opinion that design reviews are even more important as code reviews. With code reviews, you should be checking the code to ensure it matches the design but this can also be achieved with a design-to-functionality tracking matrix (making sure every aspect of the design is tested in the code).

For designs, there's no other type of testing (you can't run the design) - you have to have a matrix that maps design items back to individual requirements and, if this matrix has holes in it, it doesn't matter how elegant and clever your design is, it's not what the customer wanted.

Let me know how that works out if you give it a try :-).

Answer 7

IMO...

Design reviews should take place before production code is written, Code reviews should take place after the code is written. They have different purposes.

Design reviews help to verify the correctness, completeness and soundness of the proposed solution, while code reviews ensure that the code meets the quality and code standards of the team. Code reviews can take place at almost any stage once code has begun to be written; and can even occur on a continuous basis. It's too late, however, to change the design after the project is completed.

Design reviews can occur after a project is completed if the goal of the review is academic.

$0.02

Answer 8

We have just started doing Design reviews and so far they are working out well for us.

The main reasons we started doing the reviews are:

1. To ensure that the developers actually understand what they are supposed to be building. If they can't explain their design or the design clearly does not implement the requirements then they have not understood what they are supposed to be doing. In the past this has been a problem for us where we have only picked it up during QA after coding, when fixing it causes long delays. The design review gives early feedback and changes at the design stage are fairly easy.

2. Training for junior developers. Often I find their designs overly complicated or missing some important aspect. The design review gives a good opportunity to show them how to improve the design so hopefully they will do a better job the next time. Withot that feedback they continue to create poor designs.

Answer 9

This is good feedback. I was also wondering should code reviews be more of a team or a reviewer/coder strategy. I can see the benefits of both. The team strategy would definitely open up a learning experience for the entire team if you it is constructed of more junior developers. More expert and seniors on the team, I can see how the reviewer/coder strategy would work better.

Answer 10

They are a way to get feedback in a structured manner and help get the other members of the team on board with what you're doing.

Answer 11

Reviews are a great opportunity to ensure that everyone knows the code is doing. This is very important if you are supplementing your staff with contractors or new hires. Their lack of product experience leads to some coding errors that are best caught in reviews.

Holding a review also forces you to explain your code - it is amazing how many problems of mine I have caught by explaining the code to others.

Answer 12

If you look at the V model of software development, you'll notice that the farther from the left you go, the more money you'll spend on fixing things. Design reviews are a good way to avoid making trivial mistakes in the early phases which cascade to later, more expensive phases.