I have an ongoing and friendly disagreement with colleagues over the value of code analysis rules and training. I focus part of my time on training and coaching as I feel that this is a great investment both in people and also in the quality of the software that is developed. The argument of my colleagues is that training needs to be repeated over and over again in order to cover the large developer base and as new people arrive. Also you can do a training session with a development team but that doesn't stop them from committing bad code.
Code analysis rules on the other hand block bad code from getting into the system and are exercised every single code commit and so are more valuable than training. When combined with automated testing and code metrics you get a trifector of code quality goodness. And I do agree with that, just not the part about code analysis rules being more valuable than training.
I often get asked if I get tired of coaching because I have to be teaching some of the basic concepts over and over again and my answer is: sometimes; but in general I find coaching beneficial and especially for my team because I can see the growth of team members over time. Finally don’t forget that the best way to learn is by teaching. My unquestioned knowledge that I don’t remember from where it came gets blown away when teaching it. I usually can see this ahead of time, that my internal BS detector tells me when I need to do more preparation on a specific question because my intuition about it is probably BS. When performing training just speaking aloud is often enough to find areas of the subject that I am weak on and if that doesn’t happen then questions from my colleagues will surely find them.
Of course the answer is that both training/coaching and static code analysis is important and both need to be implemented correctly but my own personal preference is to invest more heavily in training than in static code analysis.
There are three characteristics of poor static code analysis.
· High false positive rate and therefore a high suppression rate which basically creates a culture of those annoying code analysis rules, “oh yeah just suppress that one because it doesn't make any sense”.
· The static code analysis fails to detect examples of code it should prevent.
· Documentation is non-existent or not informative. We could create excellent documentation to explain what the code analysis rule that fired is trying to protect and provide example solutions to fix the code.
Fixing these issues would go a long way to making code analysis rules more relevant and more effective. The first two issues can be caused by over ambition. You need ensure that the purpose or ambition of a code analysis rule is achievable given the time required to develop it and achievable given the technology used in the code analysis rules. The more ambitious the rule the more likely it will have false positives or completely miss examples of code that it should try and block.
Training and coaching is an investment in people. When I look back at my first job, my boss was my mentor, he was technically gifted, very intelligent and more importantly he loved to teach. The things that he taught me in my time in the job as a junior have stayed with me in my career since and have shaped the programmer that I am today. I was luckier than most to have such a talented developer as my first mentor and I don't think I would be at the level I am now if I had not had him as a mentor and guide.
Training and coaching is making that investment in people and given the right attitude of the learner can make a big impact on their development. The developers who are motivated to learn, who are thirsty for knowledge, will be able to apply the teachings that you impart and you will see an improvement in the quality of the code that they produce and their critical/logic thinking skills. It may not be empirically measurable but you can see with your own eyes the impact that this training has on them and their capabilities as a software developer.
Training done wrong is an interesting subject and I am still working this one out. I do know that in order to be effective it is better if you can get developers to write some code rather than just listen to the trainer speak. I started out in a more university lecturer style but I am moving more towards a training workshop model. For completely new technologies, such as introducing a NoSQL database to people that know nothing about them, this model is essential. I like to market these as code jams where we install the data store on each developer laptop and start introducing data and writing queries. Neo4j is a great one to start with, people really enjoy that. Another thing I have learned is that people who are not hungry for knowledge don’t gain much from training. But then they don’t gain much from one-to-one mentoring either. These people are dead weights and I don’t think much can be done about them.
Training and static code analysis really can’t be compared as their focus is different. Static code analysis focuses on blocking bad code and training focuses on enabling developers to use new technologies and write better code. But training can prevent bad code and code analysis can train given that the developer is willing to spend time reading the hopefully good documentation.
For now I will continue to invest in training but I would like to learn to write static code analysis rules sometime in the near future.