Increasing Quality - review and unit-tests

These principles aim is to increase code-quality and thus overall productivy. They aim to reduce the number of bugs which slip the development team. We know that bugs take (exponentially) longer time to solve depending to how fast they were traced.

The 3 principles are:

• design review
• unit-testing
• code review

Design review

The most important review is not the code-review but the design review. This stage is mainly ignored in most of the companies. After the design is ready (Im implicitly assuming you are doing some sort of a design before starting to code) , let the tech-leads/seniors/smart-people review it and give remarks.
The benefits of design review:

(a) change done in this change and not after the code-review , will save days of work later.

(b) change done here will most probably be actually done. A lot of code-reviews ends up saying "it should have been done differently but we do not have time to fix it and re-test it now , so leave it be". In the design-review stage these does not happen.

(c) will be used to communicate initial API between different components , helping other developers understand what to expect for.

Note that design-review must be enforced by the managers on the tech-leads/seniors , as it is usually done in the period when the tech-leads has the least time.The manager must press them on this issue.

unit test

The best way to know the quality of a component is to ask the developer what is the level of functionallity he tested. Let there be the following answers: "It may work" , "It probably works even on hard cases" , "It defentially works on all cases".

The good result should be: "It defenitally works on avegarage and it probably works even in corner cases". less then that and they did not test enough , more than that , and they wasted time on unnecerayy tests.

Developers should do extensive unit-testing , manaul , or better yet, automated ( in java the term "JUnits" is most familiar) . This developer testing goal should be to test the high-risk sections of the code. 80-90% coverage will be better than 100% coverage , if you have more tests of error-prone code.We must understand that on 99% of the features, full code coverage is both impossible and a waste of resouces!

It is OK for a developer to leave some tedious test cases to the quality-assurance people as long as the developers do make an effort to test few of these cases and knows that the code "probabily works".

code review

This is done quite commonly and its a good practice. This stage can help trace dozens of bugs very fast. It also helps to spread knowledge between team members , and provide coding feedback for the coder.

One uncommon practice in code review I want to recommend is that the code-review will be done"offline" without the original developer sitting next to the reviewer.

This will ensure the developer writes code that another human being can understand (usually using remarks, good naming conventions etc) , as he knows someone will read his code in few weeks and will suffer otherwise.

It will also ensure that no bugs are swept under the table, as you don`t talk with the code-reviewer directly.

The coder and the reviewer will meet twice : once before the code review for high-level explanation and once after the reviewer read the whole code, to share his remarks.