In the television world, experts track criminals using DNA found on the crime scene. Luckily we don’t have serial killers in the software development world, but we have what I will call “serial developers”. If I had to “profile” them, I would say that they are often young, having recently completed their software development education, or worse with no formal developer training. They love programming, which means that they like writing code. Testing is not their favorite activity, but this is not a problem for them because they are confident about their code. Anyway you don’t really have time to test in “real” projects where you are behind schedule. Wouldn’t you prefer to add more features to the product? The same features that some ungrateful users will name bugs. But why are they stepping out of the “best case” scenario that I use to check my code? Don’t we agree that users are the most important nuisance for software developers?
If this description could seem rude to you, I must confess that I had part of these characteristics in my early years as a software developer. Some people evolve in their vision of what professional software development is, as I hope I did, but some people keep the same habits. They jump quickly from new projects to new projects (yes, this is what we all want to do), often leaving to other people the duty of polishing, maintaining and evolving their wonderful code. They, and sometimes their managers, will never know about the mess they can leave behind them. Maybe we are just too dumb to understand their code?
To rephrase a famous Churchill quote about democracy: individual responsibility is the worst way to produce quality software, except all the others that have been tried. Unfortunately, in a lot of software development shops, performance is measured in lines of code and does not include any quality criteria. Personal control activities like inspections, peer review or pair programming are not very well adopted and accepted. Developers have to be educated to the long-term consequences of their coding activity. Experience sharing and transmission could take different forms as the testing dojos article in the Winter 2010 issue of Methods & Tools suggests.
Education is certainly the best tool you can use to improve the quality of the code and avoid damages caused by serial developers. As in the TV world, you can also use some tools to control software delinquency. Tools like Checkstyle controls coding standards. Potential problems, duplicate content or code complexity can be detected by static analysis tools like PMD. All the results of such tools can be aggregated in global tools like Sonar that produces a dashboard showing the quality status of your projects. All the tools mentioned here are open source, so their adoption is not a cost issue. Most developers are happy to improve their coding practices. Using a tool to produce a static analysis report of some code is an excellent starting point to discuss how they can achieve it… in case you haven’t thought yet of your New Year resolutions. Thanks for reading Methods & Tools in 2010 and I wish you all the best 2011.
I find that “serial developers” are all ages. The young can be taught and at least have energy. The middle-aged treat any suggestions suspiciously because it might further effect their downward mobility, and the old are often just spiteful but politically savvy enough to never have to accept change. Happy Holiday! :)
“Unfortunately, in a lot of software development shops, performance is measured in lines of code and does not include any quality criteria.”
I remembered an old quote of Bill Gates:
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
– Bill Gates
I’m one of those serial developers. And I can’t be bothered to do any testing on my hobby projects. Time is short, and enough bugs are obvious (not engaging in excessive error suppression) without any formal unit testing method.
Also I tend to believe that I do not practically need it. Unlike Windows “programmers” I’m not as separated from the actual runtime as All-IDE coders. But also obviously that depends on the language environment; it’s a bit of a different story if you write Java, the low-level language of the JVM.
Concerning metrics I am reserved.
It is easy to just ignore the metrics if you start to have too much work to go back to a correct state.
Here, we do have sonar and we have more than 7 millions of violations. The estimate is that I would cost us 80 millions $ to have good metrics in sonar.
A side note, is that by refactoring code to fix metrics you are likely to introduce new bugs in the code.
It is also easy of beeing too strict and to make people focus to avoid some contruct but it will not help that much.
You know if you are a great developper, you may use the ternary operator for a good reason. You may also have several return in your method simply because is more clear.
And programmers that just want to keep coding like before will just do the bare minimum to fake the reports and will continue to produce bad code.
Pingback: Sonar » Sonar in the news