Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Does your team rely on code reviews for approval of work? Is it simply QA that signs off your features and fixes? Do you have a lead programmer (or architect) that reviews code design and implementation?

Or is it simply a Works on My Machine paradigm?

What would you recommend or have seen that works well?

share|improve this question

migrated from stackoverflow.com Jan 6 '11 at 23:01

This question came from our site for professional and enthusiast programmers.

I think you should try adding some context, about your own situation, to your question. What kind of industry are you in? Who are your customers? How big is your company? On what kind of platform are you writing on? On a side-note, have you read "Code Complete"? –  Stephan Branczyk Jan 6 '11 at 22:55

4 Answers 4

Having QA review for code before it goes into production is definitely good practice and is recommended. General code review by other team developers is typically done before QA. However, the size of the team, the specific product, culture, etc. determine how the code review should be done. What I recommend is to do a code review with multiple people reviewing code. Also if you have several team members I would suggest having several people review the code not just the lead developer. Team members with less experience might not be able to identify as many issues, but will learn not only new ways to do things and become more familiar with the code that the team supports.

share|improve this answer

In our case, code ships when it meets the specified requirements. A thorough testing, review and validation process of the software is undertaken to insure that the requirements are fully satisfied.

Although we have informal style guidelines (and review of critical code), that is a secondary consideration. I work with a lot of very smart people, and code quality is seldom an issue.

share|improve this answer
Wow, that must be nice! But smart != mistake proof. –  morganpdx Jan 6 '11 at 23:34
That is pretty much exactly how we run things where I work. –  Pemdas Jan 6 '11 at 23:53

Code review is very effective when contineous and implicit within the team.

That's why it's not explicit in our Definition of Done.

Here is how it works:

  • Tasks are not assigned, team members can decide to either work alone on any task or partner with another developer.
  • They communicate trought the whole process and review each other.
  • Sometimes they decide to do pair programming which is, IMHO, the best code review process ever.
  • Pair programming ensure produced code is not owned by an individual and meet the team's coding guidelines.

With this system, it is very unlikely that a developer will work alone on his module without any external help. This behavior is natural when tasks are not assigned.

It's why it's very important to have your team located at the same place, in the same office or splitted into two 3 desks rooms.

share|improve this answer

Continuous education (by the architects to the developers) of the stuff and a team spirit where everybody is responsible for foreign work too. Control in sense of quality assurance is good but do not sufficient in critical project situation (dead lines). You need stuff that work hard to achieve the impossible, all together.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.