For many years, OKRs (“objectives and key results”) have been the gold standard in organizational goal-setting. Regardless of company size – Google and Amazon or a tiny startup – OKRs help set top-line goals and success metrics.
As engineers, we often use OKRs to strengthen the codebase and to prioritize work that is often long-overdue. Here are key results that I achieved in my career, and ways that code coverage helped accomplish them.
- Decrease downtime by x%
One of the most frustrating things for business and product teams is to see their site or application down. It causes friction for the customer, who might lose faith in the business.
The first thing we did as a company was to investigate the most common reasons for downtime. What we noticed was that a significant number of instances were caused by code that integrated with third parties. If not architected properly, integration code is often messy and difficult to test. It is further complicated by handing off code from engineer to engineer.
We wrote tests that mocked flakiness and unexpected responses from these API calls and used code coverage to ensure all error cases, catch blocks, and code branches were properly tested. We saw a noticeable decrease in downtime, as well as in engineer onboarding time to these features.
- Remove X feature
As an engineer, I have been terrified to remove legacy features from the product. Typically, this stems from not properly understanding side effects in the codebase. By removing some feature code, I could be exposing issues with models further down the pipeline.
In order to mitigate this risk, the team wrote unit and integration tests around the most likely models that would be affected. We used code coverage to inform us which lines of model code were not getting touched. By going through this process, we successfully removed the feature with very little engineer time spent on bug fixes.
Although time-intensive, writing tests and following coverage recommendations ultimately helped us remove this and future features more quickly and effectively.
- Migrate to a new frontend framework
Frontends go through a major overhaul at a company every few years to keep up with current technology, close security holes, and make it easier for engineers to onboard.
Because the end result typically has the same UI and functionality as before, a frontend refactor has to be executed with minimal issues in order to justify this goal to key business stakeholders.
Focusing on coverage for all development on the new frontend gave us confidence that there would be no disruptions to the new frontend rollout, and thus prevented pushback from product and business teams. By integrating code coverage early, we were able to quickly validate the majority of use cases, gives us time to find more challenging edge cases.
- Identify and remove dead code
Most of the organizations I have worked with, from pre-seed startups to corporations complain about the amount of dead code in their systems. Dead code makes it difficult for new engineers to understand complex systems and burdensome for veteran engineers to remember.
Code coverage can be used to help find dead code in a codebase. In our particular case, the engineering teams and product we built had grown quickly, and test coverage had been deprioritized. We first identified and wrote tests for the features we knew were heavily used by our customers. Based on what was left untested on coverage reports, we were able to identify untested code. This made it easy for us to determine where to begin removing, and if the code was crucial, to cover the code with tests.
I often hear the argument that tests are too time-consuming to write, especially on a new product that is meant to move fast (and break things). But writing the right kinds of tests and knowing where and how to spend your time enables teams to move quickly. By investing the time to cover features with tests early, a team can greatly reduce its overhead in fixing bugs and ramping up new engineers later.