Many years ago, I started my career in product management with only a basic understanding of what is code review — developers looking through each others’ code for bugs. With upcoming deadlines, KPIs, user (re)engagement, compliance, and revenue goals all competing for my attention, understanding our development team’s code review process wasn’t a priority. After all, we had a great QA team. It took some time for me to understand that code review is so much more than identifying new issues. We were working to ship critical updates to our new user signup flow, and every day without fixes had a real and meaningful impact on our bottom line. My plan was to push changes to our staging environment on Wednesday, have QA review it on Thursday, fix issues through Monday, and launch to production on Tuesday. Our team was motivated, and we got to work. Come Wednesday, the expected changes were glaringly absent from staging. Our development team found several launch blockers in code review, and they were still working to resolve them. Fast forward to the following Tuesday, and there were still no changes on staging. I was furious to learn that the code had been reviewed three times, and the last build passed all of our unit testing. I thought, “If the code is functional, then what else really matters? It’s only code. Why are my engineers wasting time reviewing code that works?” Functional code isn’t necessarily high-quality code Sometime later I inherited an application burdened by years of technical debt, with zero documentation and no access to the original developers who wrote it. Attempting to update a button’s position caused the app to fail spectacularly, and no one could explain why. But despite all of its poorly written functions in several different languages patched together using obsolete and unmaintained libraries, the app technically worked. It was functional and passed QA, yet no one wanted to work on the project, which should have been my first clue. I originally scheduled one week for our first sprint to make a handful of maintenance updates. It took eight. And the toll it took on our development team was even more costly. One of our developers felt the need to apologize: “I’m sorry this is taking so long. I’m just having a lot of trouble moving this one button.” For a developer who takes pride in her work, eight weeks of trudging through a swamp of technical debt is crushing. As a PM, you know the concrete costs that come with each day your fixes aren’t yet live, and there are also the intangible costs to your development team — a loss of trust and faith in you as a leader, in the project, and in the team to get things done. Not to mention the opportunity costs. Eight weeks spent spinning our wheels working with bad code was eight weeks we all wished we could have spent shipping features our users actually wanted and needed. Healthy, high code quality is key In addition to identifying issues, code review is also about improving code quality and maintainability. While unit testing is great at verifying that things work the way they’re supposed to, it’s not as adept as people are at offering suggestions to simplify complex functions, ensuring code is human readable, presenting alternatives for upcoming deprecations, or verifying automated tests are set up correctly. For example, imagine a simple app to charge customers for an item. The code requires a currency to be declared, and in this test case, it should be in USD. However, the currency’s default value is set to EUR and was never changed. The code will have a high likelihood of passing unit tests, and if the currency unit isn’t displayed on-screen, it will likely pass QA as well. If this bug went live, the potential cost to your business would be enormous. These are the kinds of issues that can be discovered through a rigorous code review process. I’ve learned the following lessons through my experience leading development teams: Be an advocate for improving code quality You have a responsibility to your team and to your users to produce features that are safe, secure using high-quality code. Account for code review in your sprint planning and make it a priority, not a “nice to have” that can be punted. Understand major issues identified in code review Whether you’re a technical or non-technical PM, take the time to understand major issues, proposed solutions, and timing. You’re responsible for all aspects of your products. This will help you avoid running into the same or similar issues in the future. Support your development team Starting or maintaining a healthy code review culture can be challenging, but you owe it to your team (and to future teams that will maintain their code) to establish good practices now. Helping the leaders on your development team to set on the right path today will pay dividends going forward. Invest in code review Code review is a low-risk, high-yield investment. It’s easier, faster, and cheaper to identify issues in code review than through user reports posted, forums, social media, or even a massive, costly security breach. Code review as part of a healthy regiment of development practices enables your team to ship meaningful features to your users faster, and with fewer issues in production. At PullRequest, we’re here to help. We’re passionate about code quality, and we have a community of on-demand reviewers who are vetted and ready to help add more rigor to your code review process. for more info. Chat with our team Written by Dan Mateer and originally published at www.pullrequest.com on December 4, 2018.
