[healsjnr1]

> If code reviews aren't an expected part of the development process and there's pressure on delivering, it won't happen.

This hits at the heart of why I strongly agree with this post and think PRs and code reviews are ultimately destructive.

Reviews are going to get dropped _regardless_ of whether they are in the process or not. Pressure makes code reviews and quality worse, not better.

More than that, the need to "appear" to review is going to slow things down and can cause an exponential back up. I saw this happen about a mouth ago: 3 day release cycle got bogged down and then took _3 weeks_ to get a single release out.

Process goes out the window when pressure hits. You are then operating in foreign environment at the most critical point and your safety net of useless.

Your safety net when things need to go fast should be highly automated fast build and deploy, coupled with great test coverage, from unit to end to end.

The only exception might be if you work in highly regulated field where you legal required to have a very low Mean Time To Failure. In that case things move slow unless you are very well resources.

Otherwise (ie the majority of products) focus that effort on having a very low Mean Time to Resolve. If you absolutely need some form of quality assurance, Pair. Do continuous PRs and knowledge sharing rather than out of context after the fact reviews.