Is your code a bug factory?
Many code bases are “working” but not quality. Often, there are so many bugs coming in, it is hard to work on new features. It can be hard to express to upper management why so many bugs exist. This is a quick estimate evaluation that easily give you a quantifiable number representing
whether you are bug factory or not.
You’ve heard the saying, “An ounce of prevention is worth a pound of cure.” Well, in code, you can say: And ounce of quality will prevent a pound of bugs.” But a saying is just that. How can we make that measurable? This questionnaire will do just that: make this saying measurable.
This is a golf-like score where the lower, the better. The highest score (bad) is 1000.
| YOUR SCORE % | QUESTION | DEFAULT VALUE | NOTE 1 | NOTE 2 |
|---|---|---|---|---|
| Is your code Tested? | Non-scoring header line. | |||
| What percent of your code is not covered by unit tests? | 200 | Enter the % of uncovered code, multiple by 2. | Use the default value of 200 if you don’t know the code coverage or don’t have unit tests. | |
| When you fix a bug, do you first create a unit test that exposes the = bug? |
50 | Enter the estimate % of times this is not practiced, divided by 2. | Use the default value if you don’t expose the bug with a Unit Test be= fore fixing it. |
|
| What percent of your customer use cases are not covered by automated tests? |
100 | Enter the % of customer use case that are not covered. | Use the default value of 100 if you don’t have this information. | |
| Does your code follow common Principles such as 10/100, S.O.L.I.D. or DRY |
Non-scoring header line. | |||
| What percent of the code breaks the 10/100 principle? |
125 | Enter the % of code that doesn’t follow the 10/100 principle, multiple by 1.25. | Use the default value of 125 if you have a lot of large files and methods or you don’t know the % of code that follows the 10/100 principle. |
|
| S – What percent of classes have more than 1 responsibility? | 100 | Enter the % of classes that break the S in SOLID? Hint: Estimate 1 responsibility for every 50 lines. | If you can’t get this information easily, use the default of 100. | |
| O – What percent of your code never changes because it is tested, stable, bug free, and open for extension? |
50 | Enter the % of classes that never change but can be extended? | Use the default of 50 if you have no idea. | |
| L – Do you have a best-practice for testing inheritance? | 25 | Enter the % of inherited classes that don’t have inheritance tests divided by 4. | If you don’t know what the L means and/or no inheritance tests exist, use the default of 25. |
|
| I – What percent of interfaces have more than 10 methods/propert ies? |
50 | Enter the % of interfaces that have more than 10 combined methods and properties, divided by 2. | Use the default value if you don’t know, or if the code has few interfaces. | |
| D – What percent of you code is using dependency injection? | 150 | Enter the % of classes that don’t use Constructor Injection, multiplied by 1.5. | Use the default value if you aren’t using DI. If you have DI but don’t use it properly do 75%. |
|
| DRY – Do you have standards and practices to prevent duplicate code? | 50 | Enter the % of code that could be considered duplicate code, divided by 2. | Use the default of 50 no standards to prevent duplicate code exist. If you have common libraries but they are a mess, use 25%. | |
| Do you do pair programming at least 1 hour a week? | 25 | Enter the % of developers that do not practice pair programming for 1 hour as week. | Use the default if pair programming is not a weekly practice. | |
| Do you require code reviews? | 25 | Enter the % of check-ins that do not have code reviews, divided by 4. | Use the defaul if you don’t require check-ins. If you require code reviews but have no standard code review check list, enter 13. | |
| Do you have a 1-step CI/CD process to 1) build, 2) run unit tests, 3) deploy, 4) run automated tests, 5) gating each check-in? | 50 | Enter 0 if you have it all. Enter 10 for each step you don’t have. | Use the default of 50 if you don’t have any of it, or if devs can build locally in 1 step after check-out. |
Now, add up the score in each column. Enter the score into this statement.
This code is ______ times more likely to create bugs than average.
Reacting to the Code Score
These are generalizations about what to do based on your score.
Warning! Neither me nor this blog are your company’s CTO or expert. Each project is different. These generalized suggestions should be analyzed by a company’s CTO and the expert team members the CTO trusts. It is solely their responsibility to make any decisions.
| 1000 | Max Worst Possible Score. |
| 700+ | Emergency: The code is in trouble and needs everything refactored, which will be very expensive. You need to heavily weigh the pros and cons of a rewrite. For both a rewrite or a refactor, much of the code and logic can remain in place. One option is to bring in an expert who can help you follow the strangler pattern to replace your code with new code a piece at a time. If the code is a coupled single piece, there may be prerequisite projects to decouple a piece. |
| 300-499 | There may be a few problem areas. Track bug areas and improve the code quality of those buggy areas. You may need to look at the code weaknesses and address them as projects, as incremental improvements may not be enough. |
| 100-299 | There may be a few problem areas. Do incremental improvements. |
| < 100 | Keep up the good work. |
So now you know whether your code is a bug factory or not. Congratulations on knowing the state of your code.
