The Gamification Of Good Coding Practices
February 26, 2020 Nick Blamey
There are many things that are important about creating good code, but perhaps the most important is the idea that there are good coding practices and that everyone coding, no matter what the programming language and no matter what the type of application they are creating, should adhere to some standards of quality.
It is often the case that those have spent decades automating different aspects of businesses with systems like the IBM i and its peers have been the most resistant to brining automation to the very work they do in development and operations. But if the DevOps movement that was spawned by the massively parallel – across space and time – coding in the world’s largest open source projects have taught us anything, it is that no one’s code is above automation or inspection for adherence to quality. Not every project can have a Linus Torvalds maniacal genius maintaining code quality, but there are tools, infused with the good coding practices of decades of work by programmers, that can nudge newbie programmers in the right direction and even teach a few old dogs some new tricks.
CodeChecker from ARCAD is one such tool, which in this case can analyze and annotate programs written in RPG III, RPG IV, ILE RPG, and RPG Free Form as well as CL and ILE CL programs and all of the SQL query language variants available on the IBM i and predecessor platforms. But CodeChecker does much more than just do what is akin to a spell checker in a word processor application. There are some important things that such an automation tool delivers to IT organizations that are more subtle but not less dramatic in their effects on the running of that organization and the quality of the applications that it creates.
For one thing, having a code checker is like giving programmers of all experience levels an educational tool, and is especially useful for inexperienced programmers or those who are unfamiliar with RPG, CL, or SQL. It is not cheap to send an inexperienced RPG programmer offsite to a week-long training course, and it is similarly not cheap to bring RPG trainers onsite. Tools like CodeChecker educate programmers as they work, and that is a kind of continuous improvement for code development that pays for itself in a relatively short time.
Continuous code checking also feeds into the compliance needs of the IT organization as well, since IT organizations are supposed to have peer review of alterations to applications to make sure nothing nefarious or inadvertently dangerous is happening in the code that might put the business or its data at risk. The automated code checking tools can do a first level review of the code, allowing programmers to spend less time doing a formal code review and more time actually focusing the peer review of applications, which in turn leaves more time to work on the applications that run the company and presumably lead to more revenues and the chance to have more profits. One other thing: All new programmers make a lot of mistakes, and code checkers also have the effect of making criticism instructive and less personal, which for many programmer types makes it easier to take. None of us like getting and most of us don’t like giving direct criticism, and code checkers can help make this easier.
The other key aspect of code checking is that if companies don’t do formal code reviews, either with the assistance of tools like CodeChecker or manually by looking over each other’s shoulders, they are building a kind of technical debt, which increases with time, into their applications – a debt that will be paid off in the future either by having to radically rewrite code or by moving too slowly to chase new opportunities and therefore losing business. We only have anecdotal evidence of this, but companies that have automated code checking along with their peer review of applications believe that they have fewer defects and lower technical debt.
If it is important to have continuous code checking in the IT organization, imagine how important it must be to have it when programming work is farmed out to third parties. The last thing in the world any IT organization that is spending money on outsourced application development or maintenance, either because they don’t have enough budget to do it in-house or enough people to do specific projects, is to discover after the fact that the new code from the outside is not up to the same level of snuff as the code created internally. Automated code checking, used on a continual basis and integrated with application development tools, keeps everyone using the same syntax and grammar, just like a spell checker does for everyone who communicates as part of their job.
The most seasoned programmers, who are arguably the most valuable people in the IT organization and therefore the worst people to have doing tasks that don’t result in generating revenues, also cost considerably more than other IT personnel (about twice that of system administrators who keep the platforms running). If such experienced programmers spend three hours a week doing code review, and the code checker can eliminate about two thirds of that time, then that seasoned programmer now has two hours a week back to do creative things rather than checking the work of other less experienced programmers. And the one hour that they do still spend on code review will be for things that truly warrant it.
It is not hard to justify the cost of automated code checkers. It would cost around $10,000 to send a relatively inexperienced RPG programmer to a week-long training course, and covering the cost of transportation, lodging, and food during that week could add another 50 percent or so to the bill. Doing the training on site or doing it offsite also has a secondary course because while programmers are training they are not coding, so that week of their salary doesn’t produce code during that week and the backlog grows a little bit, even if it is a good investment over the long haul. Then, you need to reckon the cost of not having proper code review when the auditors come to visit and what the true opportunity cost, in terms of bad code and technical debt, will be when the company needs to make changes to the application stack and the code is not intelligible and consistent as it should be.
The other thing that everyone is focused on is security – what we call DevSecOps to make it clear that security is right in the middle of development and operations and has to be a part of the overall architecture of the system and its applications from the get-go. Automated code checking can help find security holes before they are accidentally left open in production applications.
All of these aspects of code checking are meant to shape coding practices in a subtle but consistent way, but there is another facet to this: The gamification of coding. If people know what the targets for good code are, and the code checker is constantly telling them, then they can feel like they won a game if they don’t have the code checker complaining to them about code.
Perhaps we should add a low score counter to CodeChecker?
If you want to lean more about the intricacies and benefits of test automation and source code analysis, including code checking, we have written a detailed white paper at this link that gets into the nitty gritty details, including the economic analysis of the cost of catching defects when they are introduced or when they need to be repaired in production applications. Also, we have put together a webinar, called Continuous Quality Checking For Your RPG Code, which you can watch at this link. And if you have any further questions, you can always reach out directly to ARCAD. We are here to help.
This content is sponsored by ARCAD Software.
