For most people, quality concepts such as code complexity, test coverage, and source duplication are easy to comprehend. But the idea of making code “defect resistant” might not be implicitly clear.

Perhaps it is because the phrase “defect resistant code” really addresses more than just the code itself: it is a collection of practices, processes, coding metrics and technology infrastructure. These are all combined to make it difficult for a developer to introduce a defect into a code base.

At Stelligent, we often talk about the “lifetime” of a defect. All software professionals understand that defects will be introduced during development. The question we like to ask is, “How long will that defect live in your source management system?”

Effective organizations find ways to shorten that lifetime of a defect by using a combination of developer testing, automated analysis frameworks (that extract and report on factors such as code complexity and test coverage) and an automated testing and build framework (that builds and exercises unit tests with every material source code change).

The result is that code containing a defect will trigger a series of events that immediately communicate to the developer (and team) that a defect has been introduced.

Maybe it uses a little literary license to declare the “code” itself to be defect resistant. But the result of this collection of practices, coding techniques and automated processes does have the effect of making it difficult to add new defects to the existing code base.

All organizations that develop software should view their source code as an asset that should be protected. A great way to protect code assets is to prevent defects from impacting their stability and tolerance to change.

Organizations that make their code “defect resistant” improve their ability to efficiently deliver reliable, effective and high-quality software solutions.