For a lot of people out there developing software, life is pretty simple. I say this not because there’s anything simple about software development, but because life around the practice of software development is simple. You come in, spend the day doing what the software needs to have done to it, and you go home. Maybe every now and then you stay late some days to make a push.
As organizations get bigger and more specialized, however, the outlook starts to change. Growth brings larger and larger headcount, which, in turn, means more communication channels and general, bureaucratic overhead. Growth also brings more outsider scrutiny and general public interest, particularly as companies go public and make headlines. Such organizations start to become regulated.
Simply put, a regulated organization is one in which the government takes an interest. Legislation about how the organization much behave is created, enacted, and enforced, the latter often coming in the form of check-ups, inspections, or audits. Large companies may find themselves regulated in ad hoc fashion, or it may happen due to their size and public influence. Other companies are regulated at any size, simply by virtue of their industry. This latter designation applies to the finance, energy, healthcare, and defense industries, to name a few.
The Productivity Impact of Regulation
However your company comes to be regulated, the impact on you, as a software developer, is noticeable. You have to do stuff with which your peers at other organizations needn’t bother. You need to follow certain protocols for database access or document your code in certain ways. Often times, and at larger organizations, this takes on a “death by a thousand cuts” status in your life, and it starts to feel as though you do a lot more box-checking than software development.
This, in spite of the importance of complying with this regulations, is an untenable state of affairs for a group. To put a point on it with hyperbole, one surefire way to have your software comply with all regulations is not to write any software. And, while that’s clearly never the actual mission of your company, it can sometimes feel that way as regulation compliance starts to swallow your time.
Targeted Code Review
Code review, properly applied, can help.
In this case, however, I’m not talking about what most of us think of as the standard code review. The standard code review is one in which groups put a second (or third, fourth, etc) set of eyes on each change set committed by a developer to look for anything that might seem amiss. That’s an activity with plenty of value, but in the “death by a thousand cuts” world, it just means 500 cuts for each person.
To combat the problem of all developers needing to have too many compliance concerns in their head at all times, a helpful strategy is to specialize, at least when it comes to code review purview. Specializing in code is a dicey proposition because it leads to silos and hoarding of knowledge. But specializing in review purview can help to relieve the pressure on each developer to keep dozens of checklist items in his or her head.
Make no mistake, this is not an activity designed to absolve individuals of any responsibility for regulatory compliance in their code. Rather, it is intended to eliminate the need for everyone to be equally expert on all things compliance-related. 90% becomes “good enough for the rest to be caught at review,” meaning that developers don’t need to incur diminishing returns on their time chasing the last 10%. They can move on, let the expert catch that last 10%, and learn from the expert so that next time it’s 95% vs 5% and so on.
This is also not meant to replace the standard form of code review. Rather, it’s meant to complement it and to be an addition. Perform your normal code reviews for general code quality and work-checking, and then perform batched, specialized reviews for compliance as well.
Let’s take a look at some examples of what this might look like. What are some specialized types of code review?
With this style of targeted code review, you’d have someone who focused specifically on threat modeling. They wouldn’t be looking for odd use of design patterns or better encapsulation schemes or anything generalized. Rather, they’d be looking at the code purely from the perspective of how it might be exploited. This could, frankly, be applicable to just about any organizations, but ones for whom an exploit would be disastrous, such as financial institutions, come to mind.
Would the code get into an exploitable state if it generated an exception here? Is this call to the logger dumping anything that is too sensitive for operations to see? Is the person passing these strings to the proper encrypting utility?
These are the types of questions that the specialized security reviewer would be asking himself. He’d then follow up with the developers to help them get better at thinking about these things ahead of time.
It may sound strange to many of you, but there are plenty of developers writing code that directly impacts the physical world. Think of the self-driving car, or, more mundanely, think of the firmware that exists in today’s cars. Think of something like a hearing aid that, turned up too loudly, could blow out someone’s ear drum.
A review for physical safety would involve a domain and code expert looking at changes and asking herself, “could someone get hurt with this, somehow?”
Personally Identifiable Information (PII)
Another oft-regulated concern is the management of personally identifiable information. This is of specific concern around legislation like HIPAA, where people are legally entitled to privacy of medical records. This means that companies in the industry have to be extremely diligent about when identifying information is paired with medical information and who can see it.
With this style of code review, someone would be asking questions like “could this anonymized data be de-anonymized in any way” and “are we storing this in such a way that their local admins couldn’t go poking around in people’s records?”
Having these targeted code reviews is important, but there’s an equally important concern for keeping them valuable. They can’t become bureaucratic, check-the-box activities. When the specialized reviewer notices an issue, he should have a discussion with his team to make them aware and increase general knowledge on the topic. Or, even better, he should conceive of a way to automate the check or write some kind of test for it — make it impossible to make the mistake in the future.
Because while these reviews are primarily about catching potential problems, they’re more broadly about raising the team’s game without impacting productivity. And they can only succeed in this capacity if everyone involved is continuously thinking critically and getting out in front of potential problems.
A Guide to Improving Code Quality and Collaboration on Your Development Team
Software quality is driven by collaboration throughout the entire development lifecycle. This requires tools that support the process. These tools include integrated development environments, build and test automation tools, requirements management and bug tracking tools, as well as peer review tools.
In our newest eBook, A Guide to Improving Code Quality & Collaboration on Your Development Team, we look at how your development team work together to reduce defects, improve code quality, and bring these tools together.
- Defining code quality and setting coding standards
- Understanding the role of collaboration in improving code quality
- How a collaborative approach to code reviews will help improve code quality
- Overcoming common obstacles to peer reviews