Quality, for software developers comes in two flavours, there is the external quality, this is what the user of our software sees, and has to deal with, the features that are implemented the usability of the application, its what QA attacks with gusto 😉

This quality can be  manipulated to improve production, adding or removing features, deciding the minimal marketable feature set, this is the way a project is guided to delivery, traditionally!

But there is another quality that will scupper all attempts to meet deadlines, kill the creativity of the developers and make changes to the application slow and error prone, and that’s the internal quality.  A quality that is hardly, if ever measured, I am talking about the source code quality.

I have not found a good definition of good source code, although I do like this Ward Cunningham quote:

“Each routine you read turns out to be pretty much what you expected.  You can call it beautiful code when the code also makes it look like the language was made for the problem.”

But in truth if you were to ask three developers what they think makes up high quality code, you will probably get at least five different versions! but any seasoned developer knows when its absent, the code is difficult to read and understand, changes are difficult to make, because they have unintended consequences in unrelated modules, we have all seen it, we have all written it. 

But before I go on lets just dispel one programming myth, we don’t spend all day programming!


Typing is not the bottleneck.


We spend a small amount of time actually writing code, the remainder of our time is spent trying to solve problems created by the code we have written (debugging), helping other developers solve problems with the code we have written (debugging), waiting for debuggers to run, setting breakpoints and stepping thought code that works, trying to find the bit that doesn’t (debugging) and trying to think of solutions to the problems we are trying to solve (thinking). 

The actual act of typing in the code, or coding is just a small part of our day, and we haven’t added all the time spent reading code that we and other developers have written (debugging?)

cartoon programming

If the code we are working on has a low quality value, its going to take longer for us to understand, make changes and additions, and debug, so the internal quality of the codebase actually directly effects the productivity of the team, getting quicker typists is not going to work! We need to improve the quality of our code.

To improve the quality, we need a way to measure the quality of our code, and to decide what code quality actually means for us, there are a few metrics that have been developed,

“Cyclomatic Complexity” which essentially measures the routes through a method, the minimum is 1 with means there is a single path through a method, an if statement will add one to the index, as  there are now two paths through the method etc, so the lower the number the easier the method should be to understand and change.

“Maintainability”, which is an attempt to rate methods on their maintainability, which is a function of their size and complexity, in visual studio 2008 produces an index between 0 and 100 the higher the number the better the apparent code maintainability.

Additional tooling like ReSharper and Code-Rush provide visual queues of potential problems within the code, and quick shortcuts to fix the problems the programs find.

But all these tools suffer from the same problem, we are getting what the tool thinks is good code, and they are really only looking at small sections of the codebase, so its difficult for tooling to get an overall view of the whole project, they help but won’t provide the whole solution.

The only way that I have found so far to gauge the quality of my code, is to use the above tooling as a guide, but in addition, let others see my code, good, bad or indifferent, because the only time you truly know if you have hit the maintainability sweet spot is when a change needs to be made, or someone else has to read your code, and then very quickly you will find out if there are pain points! 

So don’t be shy with your code, let others see, read and talk about it, because by improving the quality of our codebase we  will improve our productivity, enjoyment and skills as developers.


About Duncan Butler

Trying to be a very agile software developer, working in C# with Specflow, Nunit and Machine Specifications, and in the evening having fun with Ruby and Rails
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s