Code Quality

As the creator of NCover I often get asked what my inspiration was and what the importance of code quality and coverage really is. Well, itâ€™s really very simple:

Customers expect more.

They want software publishers to make their software available for instant download over the Internet, pushing updates frequently. They expect software to install quickly and easily and work right the first time out of the box. Software that upgrades itself is even better. All of these things contribute to your customer's expectations for a quality product. So how can we consistently achieve quality?

Quality is not something you can add to a product; it must be built into the foundation.

It has been said that if we regularly pay attention to something it will improve, while what we ignore will languish. Software quality is achieved by not only paying attention to it, but also by understanding what quality really is.

So, what do I mean by quality?

There are qualitative measures of quality like:

Does the software solve the customer's problem? Does it do what it was designed to do?
Does the software meet all of the specifications that were defined when starting the project?

These aspects are sometimes measurable, but may just result in arguing over the definition of the problem your software hopes to solve. The measures that I want to focus on right now are the quantitative measures.

How many bugs have my customers found in my code since it was released?
Have our support requests increased or decreased since the new release? What is the ratio of support calls to users?
Has the complexity of my code improved or decreased over time? How understandable is it?
How many automated tests do I have? are they passing?
What code is tested by my automated tests? More importantly, what code is NOT tested by those tests?
Is my code getting slower or faster over time?

These are pieces of the development process that cannot be ignored.

A decade ago, source code version control software was the only real tool requirement that a software shop had aside from a compiler and maybe a text editor. If you were doing version control, then you were writing software right. Now, we've reached the point where, if you are not doing version control then you are either lazy or ignorant and there are even higher expectations like continuous integration, automated testing, stress testing, code coverage and static analysis.

My primary message is this:

Put in place measurements at key places in your development process and know what those numbers mean. Watch them and improve them. Measurement is the first step on the way to building a software development process that produces high quality products.