13 ms·

Back when I was first doing XP style development, we did everything with trunk based development (TBD). As a rule, we pushed to trunk (master) every 20 minutes

Back when I was first doing XP style development, we did everything with trunk based development (TBD). As a rule, we pushed to trunk (master) every 20 minutes or so. Since we were all co-located (i.e. in the same time zone and working relatively similar hours) it meant that there would be a push to trunk every 5 minutes or so (frequency depended on the team size, of course). We read all of the diffs between trunk and our branch before we merged our code -- and integrated with any changes. Probably most people won't realise, but it was in that kind of situation that "continuous integration servers" came into being. The idea was that after you pushed to trunk, the tests would run (and in those days we slapped your fingers if the test suite ran for more than a minute or two -- for reasons which will become obvious) and you would have a minute or two to fix any gaffs you made merging conflicts, etc. If you wanted to merge your code, you would wait until the CI server gave a green light, so if the tests were slow, it would be a major PITA. The massive upside of this process was that you always knew what your colleagues were planning to do. You saw all their progress every 20 minutes! You integrated with their changes! If you saw a problem, you yelled over the cubicle wall and said, "Hey that won't work because I'm doing X" -- saving both you and your colleague hours of wasted effort. TBD in this style is hard, but very rewarding. The main reason I don't practice it these days is because 1) We have continuous deployment and you don't want to deploy unfinished work 2) The teams I work on these days are distributed (and I'm 9 timezone hours away from their day). However, I really miss that immediate feedback and the seemingly effortless way in which everyone on the team is kept completely in sync. I've never found anything that even comes close (and I've done the "preliminary PR" thing many times).

Scarblac 8y ago
That was with a very small team? Seems that if you get to only five people or so you'd already be spending most of your time understanding their commits.
- lazerwalker 8y ago
  In my experience, not so much? You'll need to worry if you're working on tasks that touch the same corner of the codebase, but larger teams tend to correlate with larger codebases, meaning that's not necessarily more likely. That sort of XP style development also tends to come hand-in-hand with near-constant pair programming. So even if the conceptual limit is "5 sets of committers", that's still double the actual team size. And in practice, the cross-pollination that comes with swapping pairs every day or every few days means there's less of a cognitive load to needing to be aware of what's going on, since chances are either you or your pair already has context.

Scarblac 8y ago

That was with a very small team? Seems that if you get to only five people or so you'd already be spending most of your time understanding their commits.

lazerwalker 8y ago
In my experience, not so much? You'll need to worry if you're working on tasks that touch the same corner of the codebase, but larger teams tend to correlate with larger codebases, meaning that's not necessarily more likely. That sort of XP style development also tends to come hand-in-hand with near-constant pair programming. So even if the conceptual limit is "5 sets of committers", that's still double the actual team size. And in practice, the cross-pollination that comes with swapping pairs every day or every few days means there's less of a cognitive load to needing to be aware of what's going on, since chances are either you or your pair already has context.