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.

As a team lead managing a group of developers with no experience ( and see no need) in code review and unit testing, how can you advance code review and unit testing practice?

How are you going to create a way so that code review and unit testing to naturally fit into the developer's flow?

One of the resistance of these two areas is that "we are always tight on dateline, so no time for code review and unit testing".

Another resistance for code review is that we currently don't know how to do it. Should we review the code upon every check-in, or review the code at a specified date?

share|improve this question
    
Definately an interesting question - there have been other similiar questions here, but they have all asked from the programmer's side, not the lead/PMs. –  Michael K Feb 11 '11 at 15:33

4 Answers 4

up vote 16 down vote accepted

Do your team members actually agree that code reviews and unit testing are Good Things, just there is no time for these?

Or do they just try to reject the idea with this excuse?

In the first case, the solution is to Start Doing It Now. (OK, if you are in the last days before a major milestone, maybe you can wait until after - but no more.) We had that situation in a previous workplace of mine, where I was Quality Engineer, responsible for improving coding practices and overall quality. We kept deferring the start of code reviews till next week. One day I realized we have been doing this for a month or so, and probably will be continuing till the end of times unless I try something different. So I announced the first code review for that week. I told the guys "no problem if it will be imperfect, or if we don't exactly know what to do yet - we will just start doing it, see how it goes and improve things as we learn". It worked, at least until I left the company.

In the second case, you may need more education and open discussion with the team. Discuss code quality issues, ask them what they see as problems in the development process (or lack thereof) / in the code / testing etc. And brainstorm together about how to resolve these. The ultimate aim is not necessarily to do code reviews - they are just means, while the goal is to improve the development process and the quality of its output. It may well turn out that there are other, more painful issues which could be improved easier, bringing more benefit faster; then take these first. They can even be trivial changes in the environment or the process; all of these will improve team morale, build mutual trust and help the team bond.

The bottom line is, you can't force quality upon anyone - you can only remove the obstacles of creating quality. By enforcing strict rules and mandatory practices without prior team consensus, you may alienate the team and ultimately prevent the quality improvement you are aiming for. OTOH by open discussion and aiming for agreement on what the most pressing problems for the team are and how to improve the situation, you are more likely to get team support. This will make a crucial difference in keeping up the quality improvement drive in the long run.

share|improve this answer
    
+1 asking why is always good –  k3b Feb 11 '11 at 8:27
    
nice reply. Not too sure whether you have a system for code review so that they can buy into the idea more easily? I think everyone knows that review and testing is good, just that they don't see it. The goal of a good system for code review is to help him see the light, and make unit testing easier. –  Graviton Feb 11 '11 at 8:36
    
@Graviton, sure, you can do a couple of trial code reviews just so that people get the hang of it and can decide whether or not they like it. Make sure that no blaming occurs, and people keep focusing on the issues found, rather than the author. Pick the right piece(s) of code first, possibly even old code not written by any of the current team members. It should be reasonably complex but not too quirky, so that people can realistically comprehend it and may even spot some real bugs in it. –  Péter Török Feb 11 '11 at 8:42
    
+1 for saying to 'start now'. IME that's the only way to beat procrastination. –  Michael K Feb 11 '11 at 15:29

Don't give them the option. Make testing and reviews mandatory. If they don't cooperate, you can resort to some hardline tactics such as refusing untested or unreviewed promotions. If things are really bad, fire your worst offender.

I have seen cases where a team is always behind schedule because they are always fixing bugs that should have been caught by testing and reviews. A little more work up front saves much more in the long term, and the sooner you bring your team in line, the better your team will get.

Unfortunately, this can take time to really see results. To encourage the practice, your can start charting the rate of bug reports, mean time to bug fixes and rate of feature implementation. I usually find that after about six months of testing and reviews, those metrics will improve and your team will finally get it.

share|improve this answer
    
my concern is that if you have done 6 months of development without testing and reviews, by the time you need to implement those practices, they would say they won't have the time because they need to fix bugs. –  Graviton Feb 11 '11 at 7:52
    
Pretty harsh answer! –  Marcie Feb 11 '11 at 14:42
    
Sorry, I was perhaps not clear on the six months.I meant that after six of doing testing and reviews, the metrics become noticeably better. The point is that one just simply has to start with testing to get the benefit -- the gains made by testing are not instantaneously seen. –  smithco Feb 11 '11 at 18:11

The classic problem. Never enough time to do it right, always enough time to redo the work. Until people start doing the best practices, there will never seem to be enough time to do the best practices. Particularly since the wins are invisible to people outside of development.

The key for code review is that you want to review as little code as possible, as immediately as possible. That way it is easier to get the time to review it, the code is fresh in people's mind, and implementing suggested improvements will be easier. In the extreme you want to review every single check-in. A good tool to automate this is http://code.google.com/appengine/articles/rietveld.html. It is a variant of the tool that Google uses internally to force code review to happen with every check-in.

The challenge of code review was described decades ago in the classic The Psychology of Computer Programming. The problem is that programmers tend to tie their self-image to their programming skills. Which means that any time programmers are confronted with evidence that their skills are not up to snuff, there is a tendency to take it personally. This can cause serious conflicts. If you pick up Steve McConnell's classic Rapid Development he offers a number of suggestions for how to set up a code review process that reduces the odds of such conflict. (A key element is to make sure that management never has any involvement in the process.) Note that this reduces the odds of conflict, but does not prevent conflict from happening.

That said, the benefits far outweigh the costs. Just to cite one metric, IBM found that code review was dollar for dollar the most effective way to find and eliminate bugs. This does not replace your QA department by any means. But it results in far, far fewer problems for them to find. And that is before you get into benefits involving how much it speeds learning, spreads knowledge, etc.

share|improve this answer
    
+1 for actual research results. Do you have a link to the IBM pages? –  l0b0 Feb 11 '11 at 10:19
    
I don't have a link to them, but Code Complete does. –  btilly Feb 11 '11 at 14:52

Introducing tdd against the will of developpers is difficuilt. It is a hard way to learn to love tdd.

Since tdd is most efficent in a green field (or hard, costly, inefficient if tests are wirten afterwads) i would start with a small team that does implement something new. If you find two develloppers in the team that are less opposed to tdd than the others that is a good starting point. take in mind that the productivity of the tdd-developpers will suffer while they are unexperienced with tdd.

This tdd development is a good starting point for a codereview. Discuss how the tdd influenced the program architecture and how it eases softwaremaintanance.

share|improve this answer

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.