1. 10

  2. 6

    The real problem isn’t git, gitflow, or this thing. It’s (as the post opens with) teams with no technical leadership.

    Someone’s gotta be looking out for the mechanics of the team itself, just sit down and code is questionable with a team of 1.

    1. 4

      The recommendation to separately test each combination of feature flags/toggles sounds sensible, but the number of parallel tests per commit would grow at O(2^n). That’s unworkable. I’m unsure of a solution to this. I’ve only been exposed to a few feature flag setups, and they all seemed to be periodically surprised by weird flag interactions as a fact of life.

      1. 3

        O(n^2) isn’t a problem when n is small; you can choose practices that keep n manageable (eg prioritise work that finishes a feature over work that starts one, even if that increases communication overheads).

        Team practices are mutually supportive, so it’s often difficult to see how a given one could work (since in your environment it would lack its supporting practices) even if others are getting good results with it.

        1. 2

          Most feature flag setups I’ve seen have a dozen or more flags, though. Thousands of potential test combinations. I imagine you’d get some backpressure when your tests start to take forever or cost a fortune, but you’ll get that pressure really fast at O(2^n). Tests flipping each one individually with some developer-specified combinations seem to be more tenable, closer to O(n).

      2. 3

        It seems like the author would be happier using Subversion or CVS–I agree that feature toggles are neat though you have to be careful with them…just ask Knight Capital!

        1. 3

          LOVE this quote:

          “It doesn’t matter how often you have stand-up meetings, when it comes to the central method of communication, long-running branches represent dead silence. Long-running branches are the worst.”

          1. 1

            I am always happy to see alternatives to gitflow (which I think is overly complicated for many projects). This is a nice idea, but perhaps it works best with specific types of development. A few thoughts:

            If two developers are working on separate features that affect the same piece of code

            if (featureA) {
              // changes from developer A
            } else if (featureB) {
              // changes from developer B
            } else {
              // old code

            How do you rename or remove a variable as part of refactoring, in a way that makes all four combinations of feature flags still work?

            I guess it will depend on the types of changes, and how the developers communicate, if this is easier than feature branches (where the conflict resolution is deterministic at the end, and diff works), or if this leads to feature flag spaghetti, and time wasted adapting your changes to be able to run alongside another developers changes, which might end up not being merged.

            Also, what if you add a file? then I guess your build system will need feature flags. What if your build system uses globbing and you remove or rename a file? Some changes can’t both be there and not be there.

            1. 1

              I know people are going to feel differently about this, but I lean heavily toward explicit being better than implicit, and the presence of magic should be minimal, even if it means some redundant work. Redundant work can be verified and semi-automated to keep explicit things up-to-date.

              How do you rename or remove a variable as part of refactoring, in a way that makes all four combinations of feature flags still work?

              A feature branch just delays this question to the big bang merge conflict. Forcing you to do this work upfront means you talk about this with the other people working in the same code region.

              Like you say, the other side of the coin is that the feature branch might never be merged. Early merging optimizes for the happy path. But then again, if you merge your work early and discuss with others, it can’t remain in the twilight state of not merged, not discarded, which may improve coder efficiency.

              Also, what if you add a file? then I guess your build system will need feature flags.

              Just adding a file shouldn’t affect anything unless some other file references it.

              What if your build system uses globbing

              Please don’t, especially if you also automatically siphon those files into some automatic extension of functionality.

              Merge conflicts are annoying, but clean merges that have semantic conflicts are even worse.

              Of course plugin systems are super useful – when they are user accessible and are used for deployment. But then the API would be well-defined, restricted and conservative. Probably the plugins would even be in separate repos and the whole branch vs flag point is moot.

              Testing plugin interactions is probably worth an article series of its own.

            2. 1

              I really like this, especially that release isn’t a branch in its own right (except infrequently and temporarily).

              Trying to keep the deploy history in the source code repo is an unnecessary hassle; Just keep the commit hashes in some deploy tool somewhere instead. Or maybe that’s the git repo of your infrastructure-as-code code.

              Maintaining release becomes a hassle in particular when you need to revert to an older candidate, because there are definitely ways to screw that up. Not a huge hassle, but a hassle.

              No, wait, I especially like the condemnation of feature branches. But I knew that. :-)