The Disco Blog

When considering code quality, there are three aspects that have the most copasetic effect. Of course, there are other techniques and practices that positively affect code quality; however, it’s been my bag that these three, listed in their order of importance, offer the biggest bang for the buck.

The first aspect that affects code quality is developer testing. It’s been said that “disciplined personal practices can reduce defect introduction rates by up to 75 percent.” Surely, writing a developer test is a circumspect process that helps verify program correctness! And program correctness is directly related to quality, man.

At its core, a developer test verifies a portion of code in an isolated manner that can’t be achieved through latter cycle neat-o functional style testing. From a reliability standpoint, in linear systems (which are substantially less complex than software systems, which are non-linear), “the product of the reliability of each of the system’s components” equals the reliability of the overall system. Moreover:

“If you wanted to build a software application that had an SLA or QLA of 100% (or close) you’d absolutely have to ensure reliability at the individual object level. In fact, if you can’t ensure and measure reliability at the lowest level, you can’t possibly do that at the system level.”

Developer testing, you see, is paramount in guaranteeing code quality as it verifies program correctness at the lowest possible level which is unattainable via square functional testing.

The second most important aspect which facilitates improving code quality is developer testing. White box tests offer a confidence cushion that effectively facilitates refactoring, which in my opinion is “the [hip] act of improving code that has already been improved.” Without a test case, refactoring code becomes a dangerous proposition– if you can’t prove the code worked before you improved it, how can you verify you haven’t broken it after touching it? Hence, while you may feel that improving code quality starts (or ends) with refactoring, I suggest that without developer testing, refactoring is a non-starter.

The third most important aspect which facilitates improving code quality is developer testing. Code is entropic– meaning that:

“A software system that undergoes continuous change, such as having new functionality added to its original design, will eventually become more complex and can become disorganized as it grows, losing its original design structure.”

The only way to combat this natural tendency towards code clutter is through developer tests, which act as the only form of documentation that clearly states the intent of code and isn’t affected by humans forgetting to update disconnected documentation. If the code under test changes in any way, the tests will figure it out by failing, in which case, the smokin’ tests are updated to reflect the new behavioral contract. Rarely have I seen disconnected documentation, in the form of comments or design documents, stay current as effortlessly. Clearly documenting a program’s intent at all levels is surely a compelling way to repel code entropy.

Indeed, the three most important things which improve code quality are developer testing, developer testing, and developer testing, because developer tests facilitate:

• software reliability, at the lowest possible level
• code modifications with confidence
• keeping code entropy at bay through documentation that endures

Software metrics, automated builds, quality focused processes, people, etc all positively affect code quality (and are, of course, quite important), but it all starts with developer tests. Dig it?

Trackback this Post | Feed on comments to this Post