2.  Consistent Coding - Personal and Team Practices
Following established coding practices, which may vary from person to person and team to team, significantly improves productivity. These best practices include:
•  Coding policies and standards: These are commonly based on collective team experience, single-handedly imposed by an expert architect, or derived from contract conventions. These policies don't need to be elaborate, but simply cover the most essential coding aspects and, of course, be applied consistently.
•  Best practices against silly mistakes: Only the cream-of-the-crop of software developers can be reasonably certain that they don't make silly mistakes. Often, such mistakes happen not because of lack of knowledge, experience, or training, but just because of Murphy's Law, tiredness, distraction, and other human factors. It's best to have these checks implemented with automatic code analysis tools so that code can be checked quickly and thoroughly.
•  Custom checks against defects already found: One of the best practices overall is never to make the same mistake twice. Many mistakes and errors, although personally specific, can be generalized and then automatically detected by custom guidelines or custom checkers.
•  Checks for data- and flow-dependent errors: The trickiest errors often happen in specific corner cases, which may be dependent on program input data and the execution state, and typically aren't identified through manual testing. The new generation of static analysis tools can perform a very extensive search for errors (such as potential resource leaks, NullPointerExceptions, SQL injections, and other security vulnerabilities) without executing the source code they're analyzing.

Explicit published guidelines are critical to effective policy enforcement. The most effective way to enforce such guidelines is to check compliance automatically using code analysis tools. Automatic code analysis saves time, reduces the chances of issues being overlooked, and provides a reliable source of data for process monitoring.

3.  Consistent Peer Code Reviews
Code review is one of the most powerful techniques to find defects and prevent sub-optimal software. Code reviews engage the human brain, which is a very powerful analysis instrument. Studies show that up to 90% of software defects can be eliminated by human inspections, with the average being around 60%. As a rule, code review needs to be done on any new code or critical legacy code to ensure that issues don't slip through.

Historically, in many organizations, code review implementation is impacted by issues such as:

• Lack of consistent coding policies and explicit guidelines
• Review time is spent mostly on validating conformance with coding policy, not algorithm/architecture/reuse
• Issues are not recorded
• Resolution of code review issues aren't tracked
• Scheduling/meeting logistics (especially for distributed teams)
• High cost and induced boredom of participants

Some solutions address these inefficiencies better than others. Focused code reviews are known to work better on average, so a code review checklist (beyond a coding policy) should improve ROI and help address architectural considerations, code reuse, and proper use of components. Taking this one step further, automated code analysis relieves reviewers of the burden of checking compliance with coding policies. Additionally, to ensure that new code always gets reviewed, automating preparation, notification of code reviews, and tracking of issue status further improves the results.

4.  Early Testing
On average, fewer than 50% of software defects are structural, and the rest result from missing or incorrectly implemented requirements. Finding such functional defects requires testing: exercising some portion of the software according to how it's expected (and not expected) to work.

"Early testing" is typically done at the unit and component level before the application is fully assembled. The two main goals of such testing are, generally, performing functional validation of implemented code and securing handling of corner cases. Good testing tools facilitate testing of incomplete systems by using automated stubbing at various levels, which is vital for test efficiency at that stage. Consequently, dealing with missing or incomplete dependent components becomes much easier than if you were trying to do it by hand. Again, automation helps productivity.

A critical follow-up to early testing is reusing these tests in regression testing. Frequently, these early tests are very specific to the developer who wrote them (and - in some cases - run only on his machine) so it may be difficult to reuse them in any meaningful way. This approach, in fact, tends to cause more waste, by producing non-reusable tests. Ideally, any member of the development team should be able to use all available unit and component tests on-demand. This calls for well-structured tests that are maintained in accordance with source code, and can be automatically run in regression mode.

5.  Automated Regression Testing
When many people hear the term "regression testing," they think of activities done by QA or test groups before a software release. This approach is more wasteful and less effective than the continuous testing approach.

With continuous regression testing, the software behavior previously captured by automatically generated and/or user-defined tests is verified by re-running the tests on a regular basis (preferably daily) and comparing the current results with those from the originally captured "golden set." This provides developers with a safety net when they're modifying code: they can rest assured that if they accidentally break existing functionality, they will be notified immediately.

The high value-add of this regression approach is that it's automated. It's impractical to have test groups retest the same thing over and over again every day or every week - they would all quit in a month. Moreover, tests need to be run frequently so that if problems occur, they are detected and repaired without delay. To run frequently, these tests must be automated.

Developers should be able to add to the tests and execute the tests without obstacles. This can't happen if the tests belong only to the QA group. The benefit of democratic access is that individuals can run part of the test suites (to sanity-check their new code changes) as well as add tests to cover the new code they just developed. Further, if a test fails, the responsible developer needs access to the corresponding test case so he can start investigating and resolving the issue immediately. A sustainable procedure for regularly reviewing and addressing failures is a must for efficiently maintaining the test suite over time.

Report and Track Results
The famous saying states that you can't correct what you can't measure. Hence, it's important to assess the impact of any new techniques added to the software development process. A reporting system is a vital component: it can be used both to check the pulse of development and to analyze any changes that result from improvement initiatives.

Any practical system should automatically collect relevant data from the software development process, analyze the data, and make it available to all team members and management in a convenient form - typically via Web access and role-based dashboards with drill-down capability.

Since such a system is meant to assist in the decision-making process, continuous use of the reporting system is critical. Everybody involved in the project, whether it's the manager or the developers, needs to review the status and trends data frequently and assist with keeping the process on track.