It's true that
with async code reviews you’ll often get way less feedback and less ability to build in quality than with continuous code reviews (pair/mob programming), but at least you’ll also choke the flow and delay delivery.
»If you try to eliminate rework you’ll maximize it
Here’s an interesting phenomenon when it comes to the concept of rework in knowledge work. You can only minimize rework, but you cannot eliminate it. If you try to eliminate it, you’ll maximize it.
»The paradox of people not wanting to write tests
because they are confident their code works and “tests slow me down”, and then accumulating cruft and things taking ages to implement because they are scared to change the code because there are no tests.
»I don't hear enough people talking
about the way XP practices improve all four Accelerate metrics.
»If getting feedback is cheap
it gets invited more often, which means it becomes more timely, which means it’s both more likely to be incorporated and that incorporating it is also cheap.
»If you feel the urge
to write that “How to conduct humane code reviews” document, there’s something deeper wrong with a given way of working and its inherent incentive structure than the lack of that document.
»Add enough integration and e2e tests
and the frequency of running them becomes approximate to not running them at all. Meaning, as if you don’t have them at all.
»The biggest problem with async work
When it comes to flow, the biggest problem inherent to systems based on async work is that they make the cost of starting new work effectively zero (the other side doesn’t have to be available in order to start new work)
»An environment where people have no ways of exercising vulnerability
in the first place is an environment without psychological safety.
»For any type of async work, I can always find you a batch size
small enough for which the flow efficiency is terrible.
»