Programmers rely on different metrics as proof the quality of their code. If you don’t work in tech these statistics are difficult to understand at best, meaningless at worst. The point of this post is to give a non-technical explanation of some quality metrics many developers rely on and many companies require of their developers. If you’ve hired on a consultant s/he’ll be happy to provide similar statistics to you. If you’re selling your company these stats are easy added value to your intellectual property.
I’ll list out the important metrics with links to technical articles describing each in depth. I’ll keep my explanations here as non-geek-speak as possible while still being reasonably accurate. To be clear, I’m using broad generalizations in these explanations.
- Lines-of-Code. Programs are organized into functions. Lines-of-Code tells us how many lines of code are in a function. The lower this number is the easier the code is to maintain. Why? If an error occurs in a function, fewer lines makes it easier to isolate the error; the code is cheaper to maintain.
- Cyclomatic Complexity. How many different ways can your code run? If your code can execute a bunch of different ways, you’re better off breaking up it up into separate sections to isolate the different ways. Doing so makes it easier (cheaper!) for a new developer to understand the code and consequently less likely to introduce new bugs when making changes.
- Coupling. How many other things does this code rely on? The more things this code relies on the less likely you’re able to use it elsewhere which means you’re more likely to end up paying someone to program something twice. Modern coding practices keep class coupling to a minimum for maximum code reuse.
- Depth of Inheritance. Code reuse is important. Depth of Inheritance is one of many kinds of code reuse. Inheritance is a way of organizing code so that it can be written in one place and used elsewhere. The problem is something called “inheritance chains.” Inheritance chains are created when there are excessive levels of code reuse or nesting. Change code anywhere in that inheritance chain and you risk breaking a lot of code. The larger this number the more expensive it is to make changes to this code because the effect of the change is obscured. Some inheritance is fine, too much is not.
- Code Coverage. Modern programming practices require automated testing; double-checking your work using code. Declining to verify code via automated testing in today’s world is tantamount to malpractice. In the old days we used to pay people to do testing manually but technology progressed long ago to allow the computer do it for us. If your code must always do X, you create an automated test ensuring your code returns X every time you run it. Code coverage is the percentage of code verified by automated tests. You want a majority of your code covered by a well-authored automated test. Unless you’re making a self-driving car or flying to mars, 100% is too much. 100% code coverage sounds good but very wasteful because it’s still expensive to write the test the first time. Unlike manual testing, after you spend the time to create the automated test once, you never have to pay someone to execute it again. Through personal experience I’ve learned 70% is a good rule of thumb but there’s no correct answer, the coverage amount depends on how critical the code you’re testing is. The key is to add automated tests for any bug discovered to ensure it doesn’t creep back into the code base. Nothing aggravates a customer more than dealing with the same problem twice. Automated testing at the right coverage level dramatically reduces the likelihood of bugs being introduced into your product.
There’s different ways of computing all of these statistics. I spend most of my time in the Microsoft world using Visual Studio and Azure where the MS flavor of these statistics are automatically computed every time I compile my code. Included in those statistics is a Maintainability Index that gives me a 30,000 foot view of the quality of my work. All of those green dots indicate my code is more likely than not suitable for production.
Keep in mind these metrics help track the build blocks of your product, but whether or not your product is what the customer wants is a question only they can answer.
Why is all of this so important? The #1 reason is brand protection. The #2 reason is cost. The reason we strive so hard to implement as much automated testing & quality assurance we can is because of how expensive the repair is to make the further it gets away from the developer..and worse, the damage done to your brand when the customer is exposed to the bug. Brand damage is difficult to quantify, money isn’t. A $1000 repair at the developers desk will cost an organization at least $30,000 to repair.
We’ll help give you confidence in your product and QA processes. We’ll review your code and processes & provide a confidential report to you or even design an automated testing system encompassing all of the information presented here.
Please contact us for more information.