However, if we are merely performing more testing at the end of the project, we may worsen our outcomes.
Performing "additional testing" - taking significantly logger to test - increasing our deployment batch size. When we increase our deployment batch size, our change success rates go down and our incident counts and MTTR go up.
Fully integrate testing our daily work as part of the smooth and continual flow into production, and increase. our deployment frequency. We build in quality, which allows us to test, deploy, and release in ever smaller batch sizes.
Pair programming is when two engineers work together at the same workstation, applicable to the work that any engineer does in our value stream.
Another pair programming pattern reinforces test-driven development by having one engineer write the automated test and the other engineer implement the code.
Paired programmers are 15% slower than two independent individual programmers, while error-free code increased from 70% to 85%. Since testing and debugging are often many times more costly than initial programming, this is an impressive result.
Peer review process - whether it is working effectively - look at production outages and examine the peer review process.
Bad pull request is one that doesn't have enough context for the reader, having little or no documentation of what the change is intended to do.
Great pull request - be sufficient detail on why the change is being made, how the change was made, as well as any identified risks and resulting countermeasures.