Tips on persuading boss that code review is a good thing [closed]

Question

Let's say one works in a hypothetical company that has several developers that rarely worked together on projects and the Boss didn't believe that code reviews are worth the time and cost.

What are various arguments that could be presented in this scenario that will portray the benefit of code review? Furthermore, what are the potential arguments against code review here and how can these be countered?

Answer 1

If you have to justify yourself for such basic stuff, you have a bigger problem.

You are the expert, your team should decide what practices you use. Maybe you should start to convince your boss of that very important principle.

Your boss is supposed to decide WHAT to do and more importantly WHY doing it. You should take care of the HOW build it

(that doesn't means you can't suggest what and why do things in your company of course). A great boss should encourage his employees to participate in enterprise strategy)

However here is how I view peer code reviews:

Because programming is a very intensive intellectual work, one person can't ensure everything is perfect. Therefore code review ensure that:

• vulnerabilities or bugs are found before the app is shipped
• constant mutual education between developers (almost for free) is achieved
• code respect standard for easier app maintenance
• code match the requirements

Everyone is taking direct benefits of it:

• the developer that increases his/her knowledge and can pass his own to his/her team mates
• the customer/user that has less bugs and spend less in maintenance
• the boss that has more happy customers/users and spend less in trainings

Answer 2

Code review can get multiple developers familiar with same code. This is a good thing. What if the original author decides to quit or worse, something bad happens to him. If code reviews are done regularly, others can take over quickly.

Peers maybe able to spot potential bugs or performance issues during code review. This reduces QA and development effort. This can compensate for the additional cost involved in code reviews.

Code reviews promote knowledge sharing. Peers can tell of better ways or alternate ways of doing stuff. I myself have learnt a lot from my peers through code reviews.

Code reviews help reinforce coding guidelines followed by the team. If the team doesn't have one, that needs to be rectified. Code is meant to be written once and read many times. Coding guidelines are a step towards readable code. Code is meant to be readable by peers. What better way than to have code reviews to ensure readability?

Answer 3

Lots of great answers here. Some things I would add:

When you have to explain code to someone else, often in the course of the explanation the developer may suddenly realize he has a bug. I've seen it happen again and again that the dev stops dead in his tracks and says "oh wait that's wrong" before the reviewer has understood the thing well enough to see the bug.

Knowing your code will be inspected by someone else gives you more incentive to use coding standards (making maintenance easier) or use less "cowboy" methods that no one except yourself (and sometimes not even yourself) will ever understand. You don't want to be embarrassed when you show your code to someone else, so you do a better job on it in the first place. Because of the embarrassment factor, it leaves less of the code commented with: "I don't know why this works but don't mess with it." in the code base.

Developers who have the need for more extensive supervision or training are easily identified. So are the outright incompetent. The sooner you can find and address performance problems, the better off the team as a whole and the higher the quality of the application will be. It's good to find out this information before you take the new guy who needs training and assign him to the hardest, most critical part of your application.

Sometimes it is just a matter of correcting a misperception that will save making the same mistake in a bunch of other places. For instance we were recently reviewing some SQL for complex reports and found that several of our new devs had the same misunderstanding about where to find a specific piece of information in the database (admittedly the place they picked seemed logical which is a database design issue we also need to fix) that would be critical to correctly writing all the reports. By finding the problem and correcting it in the first reports they wrote, it saved the same error from happening in the rest of the reports. And something the older (in time working here not age) devs were so used to that they didn't think it needed explaining came out. It also made us realize there were some other things we probably needed to make sure the newer devs were up-to-speed on.

Juniors can learn from the more sophisticated code written by seniors (who tend to better understand error trapping and edge cases for instance) and seniors can learn from the new techniques used by juniors that they haven't been exposed to yet.

Sometimes people working on different but related parts of the application realize that they are going in two different and mutually exclusive directions. Ooops, easier to fix now.

It's not so easy to sneak in hard-coded values that will change over time just to get the thing to work now. This prevents a lot of future bugs such as things which change at the beginning of each fiscal year.

I've sometimes been stuck on how to do something and learned a new technique that was just what I wanted from code reviewing someone else's stuff.

If you are familiar with how the other members of your team think (which code review will help give you that understanding), then it will be easier to troubleshoot problems later because you will start with an understanding of how Joe would have approached that kind of problem.

Answer 4

As well as the knowledge sharing mentioned by the others, find examples of bugs that would have been found during a code review and measure how long they took to fix - this includes the time spent researching the problem and releasing the patched version as well as the actual time fixing the bug.

Take this cost, which will probably be a least a couple of days effort, and contrast it to the time you would have spent on a code review and acting on the results.

This will show your boss that code reviews are worth the expense.

Answer 5

Code Reviews Can:

• Lead to the development of a code library that can be shared
• Provide a uniform naming convention for variables, constantants, database tables
• Help streamline processes
• Can also lead to a review of the discover process and requirements gathering
• Lead to the development of widgets we can sell as addons to applications. (Build it once get paid each time we implement it)
• Lead to new products

Cons

• We don't have time for that

If that's true then how come we always seem to have time to do things two or three times for the same customer but we never have enough time to do it right the first time.

Answer 6

If you need to reference a document then I'd look no further than the esteemed "Code Complete." In it, the book describes how many errors are caught with unit tests vs peer review. It's astounding. Unit tests, if memory serves me right, catch only ~30% of all bugs while formal peer reviews catch ~70%.

Take that information, show him in the book and appeal to his financial side. It takes far longer and is much more expensive to allow bugs through than it is to catch them early.

Answer 7

How about running a demo (a one week "mickey mouse" type project) executed in parallel by two teams, one using code review, the other one not .

At the end of the week, assess the each team's quality of work, I am quite sure that the code reviewers will come off as better.

Answer 8

From Steve Mcconnel's Construx The Business Case for Better Software Practices and Software Software Development’s Low Hanging Fruit (LHF) address this. From the latter "LHF that will Not be Resisted by Upper Management" lists Inspections.

Answer 9

When presenting it, focus on the bigger picture.

List the benefits (better code, less bugs, less re-writes, etc) and mention code review as one of the techniques that you would recommend.

I would make it part of a bigger picture of doing software craftsmanship

• code reviews
• tests
• retrospectives
• knowledge sharing
• education
• book reviews
• lunchtime lectures

Be prepared to do a lot of work yourself in promoting these principles.
Most off all don't expect the persuasion to be a "one meeting and done" kinda thing.
You should build the case over time with calmness and consistently. When you are most annoyed by bugs that would have been fixed by better techniques, is often the worst time to make your case as you are more likely to be over-emotional and less rational. This might seem somewhat counter-intuitiuve but it is what I have learned over 30 years of programming. Obviously ymmv.