April 22, 2015 // By David Donahue
There's a lot of talk among developers about things like clean code, patterns, principles, simplicity... all of the things that we want our code to be. We want to craft clear, concise, elegant modules which seamlessly fit together into a beautifully designed system. We want to cleanly separate our concerns into neat and tidy classes, keep our methods small, give things semantically meaningful names, etc. But the reality of actually delivering a product always seems to get in the way. Doesn't it?
Things are complex. But complex things are made of many simple things. And it turns out that all those famous quotes and acronyms about keeping things simple are onto something. Because simple things are easier to read, easier to understand, easier to test and validate, and easier to fix when there's a problem.
And there's real business value to having a large collection of simple things as opposed to a large complex mass. On a recent project that business value became abundantly clear when the client implemented a new third party tool for regulatory and contractual requirements. This tool is a static analysis scanner aimed at identify potential security and regulatory problems in code. While the tool itself is large and feature rich, the concept is simple. You point it at a source control repository, it scans the code, and it emails you a report with everything it finds.
And these reports are extensive. Issues are grouped into categories for critical, important, warnings, informative suggestions, etc. Each one shows where in the code it was found, describes the issue, provides information and suggestions to correct the issue, and so on.
So when, after a few sprints of development, the client told us about this tool and that they were going to start using it, as a developer I was naturally concerned. While my external dialogue was something like, "Of course we can accommodate that. Let's go ahead and run the scan and see what it finds. Then my team will examine the results and let you know if there's going to be any impact to estimates or timelines. Clearly this is a necessary requirement, it's simply a matter of working it into the plan." I assume you, my internal monologue was more like, "Crap, what is this thing going to find? What am I going to have to explain?"
Before the scan was scheduled to take place, I of course at least took a cursory look through the code. After all, it's good to be prepared for these things. But in all honesty, I couldn't find anything that I would consider to be bad. No security vulnerabilities I could think of, no bad practices, nothing of the sort. And, in fact, it was pretty easy to examine the code for these things primarily because modules were isolated and concerns were separated.
Assuaging my concerns, I waited for the scan. A few days passed, and upon returning from lunch one day I found an emailed report in my inbox. Moment of truth. Though the file size seemed a little off based on what I'd seen. How could such an extensive report be only 45 KB in size? Simple...
It found nothing. Not one single issue.
The report was simply a header explaining the details of the scan. It had time stamps, server information, file counts, lines of code, and the various scanning profiles used to scan the code. And at the bottom, a simple message stating that no problems were found.
The business value? Well, aside from having zero impact to the current project, there's also the enormous sales potential in being the team which writes code to regulatory standards by default without even having to be told. This is our value prop, this is what we bring to the table. And apparently it's not something to which we even need to give a second thought. It's just... how we write code.
Would this same stroke of luck be possible with less-clean code? Perhaps, but I contend that it's unlikely. Large unwieldy methods, "god objects", high cyclomatic complexity, and leaky concerns all make it much easier for bugs and other potential issues to slip through the cracks. But when any one component is small, simple, and has only one responsibility then it's exceedingly easy to ensure that one component does its job well. Then once those unit tests are written, you don't have to worry about it anymore.
Proponents of “clean code” would be proud. But more importantly, the customer is happy and the project is that much more of a success. And we didn't have to do anything, just write code the way we like to write it.
David Donahue is a lead consultant at Magenic. If you’d like to contact us directly, email us or call us at 877-493-9369.