- this branching thing.
https://twitter.com/GeePawHill/status/921769372577861633
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:05:18 - the idea behind branching is that it provides advantages in situations where a code change is large.
https://twitter.com/GeePawHill/status/921769885776207872
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:07:21 - the idea behind non-branching is not to enter those situations.
https://twitter.com/GeePawHill/status/921769919548715009
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:07:29 - these two views seem very difficult to reconcile.
https://twitter.com/GeePawHill/status/921770124717314048
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:08:18 - i am a non-brancher. i push to head, i pull from head, i test on head, i ship from head.
https://twitter.com/GeePawHill/status/921770288227987456
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:08:57 - let's take a second to consider the arguments against living like this.
https://twitter.com/GeePawHill/status/921770443664699397
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:09:34 - first, a whole team that lives like this is constantly merging out and merging in, and that feels expensive.
https://twitter.com/GeePawHill/status/921770843600048128
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:11:09 - my counter is to point out that, as we learned with continuous integration, higher frequency of merges means far less pain.
https://twitter.com/GeePawHill/status/921771008582995968
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:11:48 - second, ongoing large-scale changes are always partially in the code long before they are ready for prime time, i.e. release.
https://twitter.com/GeePawHill/status/921771451757318144
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:13:34 - there is a technique price for this, to be sure. but there is also a substantial gain from using those techniques.
https://twitter.com/GeePawHill/status/921772066721927168
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:16:01 - the price is that you have to learn and use the various ways to prevent parts of head from being exposed to the user.
https://twitter.com/GeePawHill/status/921772299497492480
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:16:56 - these include things from feature-toggling to code re-organization, with many small patterns mixed in, like strategy and abstract factory.
https://twitter.com/GeePawHill/status/921772659062566914
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:18:22 - it's a lot of technique to learn, and hence the price. (i know of orgs who try to solve all this with one technique, but it doesn't work.)
https://twitter.com/GeePawHill/status/921772864080154624
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:19:11 - but the gain comes in two parts. overall skill, and longer periods of GAK and other alpha testing.
https://twitter.com/GeePawHill/status/921773197552439296
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:20:30 - what i mean by overall skill: these techniques i mentioned are not special cases only for this end, they're the meat & potatoes of coding.
https://twitter.com/GeePawHill/status/921773382806450176
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:21:14 - abstract factory, say, or strategy, these are techniques that have myriad applications in programming aside from hiding code from users.
https://twitter.com/GeePawHill/status/921773596447596544
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:22:05 - so my geeks will use exactly the same proficiencies they should already have, and if they don't know them, they should be learning them.
https://twitter.com/GeePawHill/status/921773718199767042
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:22:34 - the longer periods of GAK and other testing is the second gain. (GAK = "Geek At Keyboard", a geepawism.)
https://twitter.com/GeePawHill/status/921774177538990080
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:24:24 - the longer the code is in the base, the more likely we *all* are to discover infelicities before we get to release. this is of great value.
https://twitter.com/GeePawHill/status/921774461002579969
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:25:31 - a third critique of living branchlessly is that it doesn't let us hierarchicalize -- org-chart-ify -- testing & development & auditing.
https://twitter.com/GeePawHill/status/921775245832441856
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:28:39 - here we meet the ol' geepaw at his most annoying: "that's not a critique."
https://twitter.com/GeePawHill/status/921775383728525312
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:29:11 - the separation of responsibilities idea was always classic idols of the schema. looks good on powerpoint, does not work well at all.
https://twitter.com/GeePawHill/status/921776037813514242
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:31:47 - the fourth critique of non-branching is a kind of protean thing, whose rough gist is the fear of shipping defects.
https://twitter.com/GeePawHill/status/921776795334082561
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:34:48 - you've already seen one counter, the idea that the longer code is in place the more defects we can find in it.
https://twitter.com/GeePawHill/status/921776949890027520
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:35:25 - but the real counter has to match the protean nature of the fear. it's amorphous, attitudinal, and involves a huge variety of cases.
https://twitter.com/GeePawHill/status/921778137532387331
— Michael D. Hill (@GeePawHill)Sat, Oct 21 2017 16:40:08