3 ms·

I love this post, even though it gives even more evidence that the original TCR proposal is unworkable in practice. Namely, because all the bullet points at the

by mlthoughts2018 8y ago

I love this post, even though it gives even more evidence that the original TCR proposal is unworkable in practice. Namely, because all the bullet points at the bottom define different conditions that all have to be satisfied for TCR to be workable (and many more are omitted), you end up needing your unit test situation to be the intersection of a huge number of special cases that are almost never true in practice. You need (TCR doesn’t fragment commit history && tests are fast && confidence of test accuracy is high && ....). As you AND more things in there (and there are many more things to AND into the list of conditions necessary for TCR), the probability that it all applies to your working situation is going to drop rapidly except for some extremely isolated cases, and then one might question if it’s a good idea to adopt an extreme practice like TCR even when the heroic assumptions are satisfied, because it will mean mixed development practices in cases when the assumptions are / are not satisfied, and that inconsistency itself costs you, especially in a team setting. But the idea of reversing objections into statements of conditions is brilliant and I plan to practice thinking this way for sure!

iainmerrick 8y ago
I have the opposite reaction, I’m skeptical that the abstract “objections are goals” rule has significant value. But the concrete points about TCR are interesting. To address the objections about fast and trustworthy tests, you could limit its use to code that already has good tests. To address the version history objection, you could use “git commit --amend” to limit it to a single commit. So in some situations TCR may actually be usable (and in fact it’s not too far away from the process I often use! Frequent small commits with --amend)
- mlthoughts2018 8y ago
  I envy your ability to use that workflow. Across three enterprise jobs over the last 7 years, all places using git and GitHub, I’ve never worked on any sections of code where this could be tractable, except maybe for the process of using —amend in some rare cases where we wouldn’t want this history of those commits to be well separated for later purposes of bisecting to find regressions and bugs.
  - iainmerrick 8y ago
    This is not something I’d do on master, of course -- just on my own branch while working on stuff that will eventually become a single PR. I like to curate my commit(s) as I go, so that the final PR is easy to understand.
    - mlthoughts2018 8y ago
      Oh, I see. Yes, that is a very standard workflow. I also commonly address PR change requests in isolated commits as well, and then link back in the PR review page with something like “fixed in <commit hash>”, so that reviewers can see isolated commit changes fixing itemized requests, and also so that no review comments ever go without some explicit reply, either demonstrating the fix or explain why to not do it or table it for later. I guess in this sense, these items don’t have much to do with whether the big conjunction of conditions necessary for TCR are satisfied or not.

iainmerrick 8y ago

I have the opposite reaction, I’m skeptical that the abstract “objections are goals” rule has significant value. But the concrete points about TCR are interesting. To address the objections about fast and trustworthy tests, you could limit its use to code that already has good tests. To address the version history objection, you could use “git commit --amend” to limit it to a single commit. So in some situations TCR may actually be usable (and in fact it’s not too far away from the process I often use! Frequent small commits with --amend)

mlthoughts2018 8y ago
I envy your ability to use that workflow. Across three enterprise jobs over the last 7 years, all places using git and GitHub, I’ve never worked on any sections of code where this could be tractable, except maybe for the process of using —amend in some rare cases where we wouldn’t want this history of those commits to be well separated for later purposes of bisecting to find regressions and bugs.
- iainmerrick 8y ago
  This is not something I’d do on master, of course -- just on my own branch while working on stuff that will eventually become a single PR. I like to curate my commit(s) as I go, so that the final PR is easy to understand.
  - mlthoughts2018 8y ago
    Oh, I see. Yes, that is a very standard workflow. I also commonly address PR change requests in isolated commits as well, and then link back in the PR review page with something like “fixed in <commit hash>”, so that reviewers can see isolated commit changes fixing itemized requests, and also so that no review comments ever go without some explicit reply, either demonstrating the fix or explain why to not do it or table it for later. I guess in this sense, these items don’t have much to do with whether the big conjunction of conditions necessary for TCR are satisfied or not.