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.