Two crucial techniques or, two “prevent-the-worst practices”: design review and code review

Two crucial techniques or, two “prevent-the-worst practices”: design review and code review

1. Use short-and-often design reviews. Related with that, always carry over all content in one document through out the whole life cycle: Spec--design--developer test plan--developer user manual. We can freeze a version of the document as the “spec”, “design”, etc. However, carry over all content to the next stage.

a. This does not mean “developers do it all”. QA will have another test plan (likely based on the “developer test plan”), and support people and users will have their own SOP or “real” user manuals. However, carrying over all content in one document is the only cost-effective way to ensure that the spec is always sync-ed with the reality, which is really the make-or-break thing for a project/product.

b. The document must be checked-in with source code, and always sync-ed with source code.

c. Short-and-often design review is crucial for good teamwork and good communications. “Design” is the key: if there is no design, then, there is no testing plan and no spec-modeling.

d. A few more words about “spec-modeling”: users can never “give” spec so that developers can just “gather” them -- it is never that easy. Spec process is a modeling process, and a modeling process must be driven by “design”.


2. Use short-and-often code review. Related with that, always use coding standards, even for throwing-away code in vb3, vb6, and vb.net.

a. Code review must be short, but also often. It is more about teamwork (understanding each other’s code and enabling each other) than whipping people to standards.

b. However, if there are no standards, then, there is no code review. So, we need standards, even for legacy code in vb3, vb6, and vb.net. Also, whenever possible, and under the general rule that “do not mess up existing consistency or regularity”, we should use C# style in old code.