Are You Too Good For Code Reviews?

theodp writes "Why do some programmers,' asks Chris Hemedinger, 'place little value on code reviews?' This apparently includes even Programming Greats like Ken 'C' Thompson, who quipped, 'we were all pretty good coders' when asked about the importance of code reviews in his work. Hemedinger, on the other hand, subscribes to the school of thought that peer code reviews are Things Everyone Should Do. Not only do reviews keep you on your toes, Hemedinger says, they also 'improve quality, ensure continuity, and keep it fresh. Who can argue against that?'"

We need more testers / QA as well

[Joe_Dragon]

And some of that needs to testers who are NOT coders or people who are not mainly doing programming.

I agree 100%

[jlechem]

I have worked in places with and without code reviews. Yes code reviews can be painful especially if you work with some douchebags. But overall getting new eyeballs looking at your code often brings up things you hadn't thought about, etc. It doesn't make you or the other people bad, it's just how it is. Drop the ego and take some constructive feedback.

Re:I agree 100%

[flooey]

Yes code reviews can be painful especially if you work with some douchebags.

I don't think the problem there is the code reviews.

I'm not too good for code reviews

[jeff4747]

I'm too busy for code reviews.

Development schedules are almost always ridiculously compressed. There's no time in the schedule for code reviews. Just like there's no time for thorough testing.

But the software only has to be 'good enough' for people to buy it, so there's no ammunition for developers to use to get a better schedule.

The problem is poor developers...

[rtilghman]

The problem is that the need for code reviews is driven by lax, sloppy developers who don't see regression testing as a requirement, and who foist crappy, untested code that, in many cases, they haven't even tested.

As a consulting exec (experience side) who oversees software delivery I can't even begin to express the stunning crap that I see developers submit for "qa/review". Crap that doesn't even WORK correctly in the first place is submitted for testing, with the QA feedback often "Does not work". Aside from the hours of UE and QA resources this burns with useless testing, it highlights what I think is both an increasing lack of accountability and a lack of professionalism within the development community in general.

What's driving this I have no idea... less formal CS training? Looser languages? Web-centric apps? Lower end standards? Higher demand = more crappy resources? Whatever it is I'm seeing it everywhere, and it's driving me nuts. The lack of an appreciate for regression testing is absolutely insane... code reviews are just symptomatic of a larger problem, which is a lack of quality and skill.

-rt

Code review as a method for knowledge passing

[Anonymous Coward]

I tend to use code reviews as a method for showing other team members the work that I have done so they will know about the changes. I work with a large number of geographically disperse people and having 1:1 conversations about every little change can be tiresome and wasteful. Code reviews are an excellent way to get around this problem.

Another bonus for code reviews, along the same lines - is in teaching people new to a platform about the kinds of bugs to expect when working on the platform.

It also keeps me honest, did I just add a debug, or do I also need to add trace? If I forgot the trace, code review will pick that up.

Re:Pure Arrogance

[JoeTalbott]

The attitude that the ends justify the means in software engineering is a problem. Software isn't a write once and forget it product nor is usually written by one person. The more people that need to work on a piece of code the more that code needs to adhere to the groups coding standards. I would highly suggest that everyone who writes code treat it as if the code is also a part of the product. Avoid shortcuts, be neat, be concise, and look at it as if you weren't the one who wrote it.

Re:automated testing can let stuff fail but still

[pixelpusher220]

automated testing is primarily for regression testing anyway. GUI / user experience 'testing' is usually after that point, since 'GUI' is just the interface and not the back end logic. Working but looking bad is inherently preferable to looking good but not working....

Test at earliest possible moment

[perpenso]

As for testing - that's a later stage in the process of development.

Testing and code reviews should occur at the earliest possible moment and be integrated throughout development. Bugs cost less when they are found earlier.

Re:this

[Omnifarious]

My goal, as a developer, is to make sure QA never catches any bugs. When they find a bug, I'm embarrassed, as I should be. Developers who have a purposeful strategy of waiting for QA to find their bugs should be fired.

Re:this

[drpentode]

Finding a bug in your own code costs one of unit of work. QA finding a bug in your work costs 10 units of work. Having a customer find a bug in your code costs 100 units of work. Doing code reviews increases efficiency. Plus, you get to both teach and learn from your peers.

Re:this

[Anonymous Coward]

Your statement is true, if you care about the end user. If you just care about getting paid by finishing your work on time so that its good enough to sell the product and make money, then your statement is no longer true.

If the company creating the product does care not about long term satisfaction, they may just want to ship a "good enough" product that people will buy. In that case code reviews are out the window. I'm pretty sure that's what jeff4747 was getting at.

It's unfortunate that any company thinks that way, but it is the case pretty often.

Re:this

[Anonymous Coward]

And no matter how many times you tell management this, they will continue to prefer to pay the higher cost later.

Re:this

[rmstar]

Finding a bug in your own code costs one of unit of work. QA finding a bug in your work costs 10 units of work. Having a customer find a bug in your code costs 100 units of work. Doing code reviews increases efficiency. Plus, you get to both teach and learn from your peers.

That's all nice and dandy, but the problem is that in reality it still makes sense sometimes to produce and sell buggy software. This is so for a variety of reasons. Amongst them the fact that actually pulling off a business is a very multifacetic thing, and the product is only one of many aspects. In many cases, the cost of making a good product is simply prohibitive when viewed in the grand scheme of things.

Reality is messy.