I've attempted this, like it, and it seems to work if:
- you use Git.
- fast, then good CICD build
- ability to pair program with colleagues
I wouldn't want to try using SVN, CVS, etc. where built-in merging and diffing is super primitive. You'd need something like BeyondCompare or another manual diffing tool just to keep your sanity and help merge conflicts as they arise.
The build has to be under 10 minutes, automatically deploy to some lower environment, automated quality gates with at least unit tests that validate "the code works", including after deployed. Notice I said fast first, THEN good. If you have 24 quality gates and it takes 30 minutes to deploy code to dev, you'll just deploy manually skipping the build process and not care if it breaks. Once fast, good is "it validates if our code actually works or not". If it doesn't, no worries, see what code snuck through, and add tests for it so that kind of type of bug can't make it through in the future; all about that iteration.
Pair Programming allows you to do code review as you write the code, resulting in better code, and a lot less worry your build won't catch problems. While I like to think me + TDD == well designed code, sadly (happily, heh) I work with smarter people than me, so together we come up with even better designs.
Designing the work to allow multiple pairs to merge easier at the same time is hard. Improving your build while keeping it fast is hard. Improving your pair programming work & team rotation schedule is hard. I'd rather suffer and learn how to get better at those 3 than continue using PR's.
Top comments (0)