Friday, June 24, 2011

Code Reviews and Quality

Are code reviews the best way of building in code quality? Although good practice, code reviews do not assure quality, instead it inspects it. To build in quality you need to ensure your requirements are good, give your team members time and make sure they have the knowledge they need to build the software.

Test/behavior driven development increase code quality; it drives requirements to the specification point like no other tool we have right now. If you start writing test cases that only cover the happy path, and then you will probably end up with the same quality when producing only user stories or nothing at all.

Of course, reviewing the acceptance tests with the engineers writing the code before they start is a good practice; it communicates the intent of the test cases and features.

Deadline pressure drive developers to compromise quality. Sometimes you have to compromise on elegance when the feature you are working on is now two weeks, or more, late and you're stuck on a problem that you can't seem to find a solution for. Having mandatory code reviews will aggravate this problem, not address it. Developers now have to set time aside to allow for code reviews thus compressing the time they have to create elegant solutions.

Why not eliminate deadlines? (Just kidding) Instead of estimating features, perhaps use SLAs based on past history. If small features in the past took 2 weeks to get done with 95% confidence, the chance of it being done in two weeks is 95%. This technique helps to set the right expectations with your stakeholders.

Another approach is to review the estimates, that is accomplished with Planning Poker for example.

One other reason for bad code is developer lack of knowledge about the domain, tool used, etc. Code reviews help, but instead of reducing rework it increases it. Precious resources were spent writing the code and more will be spent reworking it to conform to re-viewer's suggestions.

Pair programming might be more appropriate for this problem. Have the new developer pair with a more knowledgeable developer. If the new developer is the one writing the code with the assistance of a more experienced one, learning will probably occur in a less adversarial environment and code will come out already reviewed. No rework necessary.

Having code inspections/reviews are good, but they won't build quality in. At most it will inspect it afterwards. Code quality creates an adversarial environment where people feel threatened and defensive -- not the environment most conducive for learning.

ShareThis