There is a lot of bad code out there. You know the kind I am talking about: Code copy and pasted all over the place. Little to no documentation. No unit tests. Poorly named variables. Confusing architecture. For a software developer working on such a code base, it can be a pretty miserable experience.
To make matters worse, poorly written code is self-propagating. The Broken Window theory describes the tendency of acts of vandalism to dramatically increase once the first act has been committed and observed by others. As described in the popular book, The Pragmatic Programmer, the Broken Window Theory also applies to software development. If a programmer sees a section of code copy and pasted, he is more likely to copy and paste code himself. Conversely, if that same programmer is working in a code base that doesn’t have any “broken windows,” he is very likely to try hard not to introduce new ones himself. No one wants to appear as a bad citizen, whether that is in code or society. The million dollar question is how code gets into such a state and what actions can be taken to improve things.
Since software entropy tends to increase as more and more bad code is added, everything must be done to stop the source of the problem before it ever takes root. But what can be done? We’re obviously not doing enough because the world is still filled with bad code. A Smart Bear 2014 Survey of over 500 developers found 25% were not satisfied with the quality of code they helped produce! Let that sink in; a quarter of professional software developers think the code that their company puts out is sub-par.
Pull request code reviews are a great way to limit broken windows. They allow a second set of eyes to review code prior to making it in the code base. But even this process does not ensure optimal quality. There are some reviewers that are busy with other things or do not feel like taking the time of doing a proper review so just rubber stamp it. There are others that take it to the other extreme by nitpicking. Oh, you’re missing a period in your comment. Rejected!
What is really needed is a simple tool that can add a bit more standardization to these software development processes. A tool like checklists. In his book The Checklist Manifesto, the author Atul Gawande talks about how checklists improve the outcomes of diverse and complicated activities like surgeries. In one example, he talks about how a checklist developed by a doctor dropped the ICU infection rate for Michigan hospitals participating in the checklist protocol by 66%!
“Under conditions of complexity, not only are checklists a help, they are required for success.” — Atul Gawande, The Checklist Manifesto
Software development has the same ingredients that make surgeries right for checklists. Software development is complex. There is a diversification of languages, skills, environments, etc. And everyone appears to be doing their own thing. There are automated tools like CheckStyle that offer a bit of standardization in terms of coding style, but things still get forgotten and missed.
What I am purposing is a standardized, simple code review checklist. The code reviewer would have to verify that the code change meets the criteria of each item in the checklist. The pull request could not get merged until all items in the checklists are checked by the reviewer.
I am not sure if checklists will save software development, but it will surely lead to better code quality.
