As most software development managers and engineers know, code reviews provide numerous benefits. It’s also known that developers are lucky if they can spend half of their time actually coding. In the quest to meet deadlines, some managers may look at reducing the time they allocate for code reviews. An effort to increase productivity at the expense of product quality is prone to be highly counterproductive in the short-term and long-term.
For that matter, the long-term prospects of any software project is not likely to get a lot of attention, except perhaps from the project owner. By taking a look at the long-term, both managers and owners can come to better appreciate the importance of code reviews as an important “early step” to improving developer productivity.
Software Lifespan
Today’s software has a lifespan of 6-8 years, but can be twice that for complex programs. At the same time, software developers tend to change jobs every two years. It’s likely that the entire staff of a development team may change multiple times before the software is retired. It’s important for software engineering managers to take steps so code can be easily and consistently maintained in the long-term across multiple team rotations.
Technical Debt
Technical debt is commonly defined as, “a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.” Technical debt is inevitable, because other software and electronic devices have their own lifecycle, too.
Over the course of just a few years, operating systems change, third-party providers that make new features and functions easier spring up and go out of business. Popular programming languages may go out of style. It may be harder to find developers willing to take on legacy programming languages. Formerly complex scripts may be replaced by new API’s, but that can be difficult if the code isn’t periodically refactored. Security vulnerabilities emerge with old and new software alike.
All of these factors and more guarantee that changes will be needed to your software. And though it may not be technical debt per se, as new technologies come online, your software may require upgrades to simply remain commercially viable alongside your competition.
Reading vs Writing Code
Invariably, developers will spend more time reading code than writing it. Before any developer can make changes to code, they need to read it and understand what it does and how it fits with the rest of the program. Over the software’s lifetime, several developers will need to read and understand the code. Any changes that a developer makes to the code will need to be tested and reviewed by at least one other developer before it is committed to the master code base.
Coding Standards
Each developer comes with their own experience, programming and style preferences. That’s a recipe for chaos. The first and most persistent tool managers have at their disposal are coding standards. Coding standards serve as a sort of Standard Operating Procedure that all team members must apply to when working on your software.
These coding standards or conventions can include rules for all aspects of coding from indentations and comments, naming conventions, programming language style guides, and other best practices. Coding standards help to keep everyone “writing in the same language” – in a manner of speaking. Ultimately, everyone who works on your software will be able to read the code faster and identify coding issues and bugs easier.
Code Reviews
Software developers conduct code reviews to spot any mistakes or bugs in software code, and hopefully to help enforce coding standards, too. Here, we’re focused on the four types of lightweight code reviews suitable for being conducted daily. Formal code reviews (Fagan inspections) involve more stages and participants and generally aren’t conducted daily.
Of the many code review tools and best practices, it’s appropriate to highlight some important details:
- It’s best to limit code reviews to about an hour each. This is suitable for reviewing ~400 lines of code in enough detail to identify 70-90% of defects.
- For optimal efficiency code reviews should be conducted in close proximity to when the code was written or modified while it’s fresh in the developer’s mind.
- Most code reviews should be conducted by one’s peers – with similar programming knowledge and experience. All developers, including senior developers, should participate in and rotate in providing code reviews to help break down knowledge silos.
The Benefits of Code Reviews
Computer programming courses provide new developers basic skills and an understanding of how to build upon them. Each company and team has their own way of doing things – style guides, work processes, git repository branching strategies, etc. Code reviews provide “on-the-job” training specific to your environment that’s not easily acquired otherwise.
A daily code review equates to about 250 hours per year. That’s the equivalent of an entire semester of classes. Code reviews are one form of continued education and an easy way to help with the onboarding of new developers. And, as your developers are likely to change, code reviews help ensure that product specific knowledge is passed on and not lost simply because one team member leaves.
Code reviews are focused on finding coding defects before they can cause costly problems. Defects that somehow escape testing and make it into production can result in major problems for your client and their customers. Not only does that have the potential to make them upset, you’ll have to fix the problem. No time was saved and you risk losing your client.
Where The Longest Journey Begins
Do you see how everything fits together? Having a coding standard is one of the first steps to creating software that will live long and be profitable. Once it is defined, code reviews help to reinforce and enforce it – help prevent code rot, make code easier to read, faster to understand, less complex to refactor. The benefits don’t end there, but if you’re looking to increase productivity, don’t cut down on your code reviews.
Follow TechRado for more!
