Last week the SmartBear development team spent time at the Embedded Systems Conference here in Boston. Even though it’s been a few years since we’ve attended this conference, our team walked away with some major observations about the embedded software space and peer code review. One of the most notable observations was related to one simple question we asked every attendee who came to our booth; “what do you do for code review?”
It’s a concept that everyone knows about, but not everyone is doing it – even if they know they should.
Developers Are Not Regularly Doing Code Review
During each conversation, developers revealed that they are not regularly doing code review. If some of them were, the process is typically happening in a conference room or via email. When it comes to editing the necessary code or checking on notes after the meeting, we heard that information often gets lost in the shuffle; emails either can’t be found or the notes don’t make sense after meetings.
As we discovered in our 2014 State of Code Review survey, code quality is one of the primary concerns of any software team. Although specifications may vary by industry and by company, one thing remains the same and that is code quality is imperative.
While we were speaking with conference attendees, each indicated that they knew about the importance of code reviewing during the development life cycle. Even if they knew how important and efficient code review was, nothing has been moved forward in terms of improving internal processes. As it was highlighted in our 2014 State Of Code Review survey, organizational barriers are often the number one reason why a development team cannot engage in regular code review.
Finding Software Defects Early Increases Overall Quality
But why is there a need for a peer code review solution? As the book, The Best Kept Secrets for Peer Code Review states, implementing peer code review can help catch bugs earlier and more often, before it gets to the QA team. By catching bugs before the QA team does, you are actually cutting the cost in half of what it would cost to fix the bugs beyond QA.
There are also additional reasons to implementing a modern day peer code review solution as this 2012 study with Microsoft developer’s highlights. While finding bugs and defects earlier in the process is extremely beneficial to the team, having a process of best practices and fostering collaboration within the team are also some of the added benefits.
In the software industry, if a bug is found then an update is easily deployed through the software. Similar to how the video game industry was, you wouldn’t have had the opportunity to update the source code if any defects were found after the game was released.
However, in the embedded software space it is either extremely difficult or near impossible to provide an update if a defect is found after a release. (Hence why you honestly need to get it right the first time.) Thus, a peer code review solution leads to better quality software, which is especially important in the embedded software space.