The Code Quality Continuum
What does it take to write high quality code?
Here’s a little table that I use to judge my own code quality:
Future axes to add:
- Ratio of the initial development cost to the long term maintenance cost
- Code testability: Code can be manually tested, code can be tested with automation, code can be tested via continuous integration
3 comments to “The Code Quality Continuum”
Imagine I have some code that’s complicated. It’s complicated because of the nature of the problem, not due to over-engineering. Now imagine I give that code to my coworkers and it meets all of the requirements of good code quality except “My peers can change it without adding bugs”. The code is therefore not the highest quality. The next week I deliver some comprehensive unit tests which enable my peers to make enhancements without adding new bugs (because new bugs are caught by the unit tests). Now suddenly the code quality is improved even though I didn’t modify the code. My gut tells me that this is wrong, that you can’t improve the quality of code without modifying the code. However, when I think of unit tests as a form of documentation that documents the intended usage and the absence of some bugs then the ability to improve code quality without modifying the code makes sense.
Evan, I totally agree. I also believe that sometimes code can be written in a readable fashion, but in a way that is non-testable. For that reason I’ve begun to believe that testability should be a third axis on this continuum.
For workability, add the level “It works for my development team” (between you and QA). Maybe too fine of a point, but one I have commonly experienced: code runs fine on/in a properly set up development environment… and no where else.
Having “improved” workability, I wanted your testabilityness axis to have 5 levels (like the rest)
I can manually test code (only)
> code can be manually tested
code can be unit tested with automation
code can be unit and integration tested with automation
> code can be tested via continuous integration
five by five! (by five)
Note the split to automation. “Integration” is a weak word, but it means “in an approximation of its full environment”. The smoke test or running a game with a button-mashing player simulation monkey are examples.
I was trying to think of a way to express “quickly testable” but gave up. Yes, it is less important and probably not worthy of an axis, but having worked on a project where the automated test suite took 18+ hours to run (and it’s success was a gate to committing to the main/master/trunk branch) I have seen testing go bad. It had good coverage and testability, but the pain level was high.
Another factor is code coverage in your tests… but again that is a factor, probably not an axis.