Changing the wings while flying, can code be made more testable and code coverage increased to 80% while still meeting the business project deadlines?

An update to the Quality Feedback TSS Post

 

I published this on TheServerSide almost 2 years ago as Build a Quality Feedback Loop Using Sonar.  As an update, the team of 50 developers has increased its code code coverage in 3 years from 30% to 80% (both line and branch) without slowing down business development.  The number of tests has increased from 2,000 to about 30,000 now.

 

The number of business defects in an application tracks with the number of technical defects.  More technical defects normally means more business defects.  This means that technical defects can be used as a metric for the overall quality of a development approach.  Sonar is a great dashboard for tracking code quality at the project and file level.  But how can it be used to as part of the daily workflow? With a little work, key Sonar feedback metrics can be integrated into the code/test/commit/build cycle at the individual level.  Code quality becomes visible to individual developers providing immediate feedback.

Implement a Zero-Defect Enhancement Process.  Integrating Sonar metrics into the build cycle enables the automation of a zero-defect code quality policy.  Use the metrics to inform developers immediately of a quality regression.  Every submission can be monitored so that developers can quickly correct and resubmit the corrected code.  Code quality increases as a by-product of the enhancement process.  Code correction early in the project reduces the number of large re-factoring projects leaving more resources for projects that automate the business.  Code quality is automatically enhanced as a part of the normal development process.  A system with active enhancements can realize a 15% to 25% annual increase in quality just by baking quality into the build cycle.

Code Quality Czar.  As with any quality program, management support is crucial.  Like all metrics and quality measurement and management programs there is some overhead.  A typical rule of thumb allows 1% extra overhead to measure productivity and quality.  In this case, management must have an experienced Java developer or developers available to answer and resolve developers’ inevitable code quality issues and questions.