As DevOps engineers, developers, and tech leaders, there are only three things that should matter to us: Quality, Speed, and the ability to maintain both over the long term (LQT - Long-term Quality and Throughput).
Think about it—everything we do as a software development team is an investment in at least one of these categories:
Quality means building something that users want—something that works, solves the problem, and meets stakeholders’ requirements, including security and scalability.
Well-structured, maintainable, and clean code doesn’t fall under “Quality” but fits into the category of “being able to maintain both for a long time”, LQT.
If you accumulate tech debt, lack testing or documentation, you’ll eventually have to sacrifice either quality (something will break) or speed (spend time refactoring and documenting old code). Documentation, linting, managing tech debt, and fostering a strong company culture all contribute to this category and indirectly support both quality and speed.
Speed means what it means. Ship fast. Short time to market. Design, code, review and deploy.
The amount of investing into one or another aspect depends on the business stage and market situation. But you cannot ever leave one of them completely behind. Usually larger and older companies tend to focus more on quality and LQT while early stage companies prioritize quality and speed.
Every metric and framework in the space (like DORA, DevEx, and Space) also falls into one of these categories: Cycle time (Speed), MTTR (Quality), CFR (Quality), Feedback loops (Speed), Cognitive load (LQT), Diffs per engineer (Speed), etc.
Note: I think it’s also useful to correlate financial metrics like ACV, or churn & LTV to measure quality.
Every tool we make or buy should work to improve one or more aspects of this equation: CI/CD (Speed), Load balancers (Stability of the system) (Quality), Documentation (LQT), Copilot (Speed), Linters (LQT).
In essence, every tool and process in the software development lifecycle (SDLC) should contribute to Quality, Speed, or Long-term Quality and Throughput (LQT).
While most tools and processes primarily focus on one or two of these aspects, there is one critical process that significantly impacts all three simultaneously: code reviews.
Code reviews: The single process of SDLC that impacts the three categories at the same time.
Speed
On average, every PR spends 39% of its time in the code review stage. So this is an example of what leaders might see when checking their team’s engineering metrics in Pullpo’s dashboard:
And this doesn't mean that devs spend 2 days straight doing code reviews nonstop. But since it's an asynchronous process, it gets blocked while devs are doing other tasks.
Sometimes there is no problem with that, but when the code review notification and collaboration system is bad, devs stop prioritizing teamwork and unblocking others over individual tasks. And that comes with a huge cost to our ability to ship things fast as a team.
→ How we created a solution for slow code reviews.
Quality
This is the first thing that comes to our mind when we think about code reviews. Does this meet the task requirements? Will this work for all our users in all different edge cases? Are there any bugs? Will it work at scale?
In some cases, it is useful to involve non-technical people in the review process. For instance, some teams may open draft pull requests to make sure everything aligns with the UI design requirements. This is one reason why Pullpo’s PR-Channels on Slack are useful, as it enables additional stakeholders to join the conversation.
LQT - Long term quality and throughput.
There are two aspects related to LQT:
First, during code reviews, we ensure the code is well-organized, tested, documented, and stylistically correct. This contributes to LQT by guaranteeing speed and quality for the long term.
Second, the way feedback is given is crucial. Code reviews—whether async or pairing—are where most knowledge transfer happens between developers. It's also where the most feedback is given, greatly impacting engineering culture and LQT.
Using conventional comments, asking questions instead of making accusations, resolving back-and-forths efficiently, and making a habit of praising colleagues for good work—all of these practices help improve LQT.
Final thoughts.
Code reviews are the single process that affects all three of the critical areas of any software development team.
Measuring those areas can be tricky, but useful.
Improving some parts of the process can have little cost but great return.
If you want to meet the founders and chat about the product, reach out! We love to do that :)
Top comments (0)