4 ms·

I think that's fine for solo development but as soon as you have a real collaborative project -- which, supposedly, is why you need a peer-to-peer vcs, then the

by rsj_hn 5y ago

I think that's fine for solo development but as soon as you have a real collaborative project -- which, supposedly, is why you need a peer-to-peer vcs, then there comes a time when dev A is working on some feature for the future, and dev B is debugging on an existing release, and now you really need branches because B's fix is going to need to be pushed out ASAP but dev A's feature is still being worked on.

Aperocky 5y ago
But that's what I'm describing (I do work for one of the FAANG), all feature work are either ready, or gated by feature flags. With practice, it becomes easier to divide feature work while not cause any existing impact, it also forces you to make your code logic cleanly separated. The biggest benefit of this approach imo is the drastically reduced chance of a bad feature going out because someone had worked on it for 5 months in isolation and it becomes virtually impossible to debug.
- rsj_hn 5y ago
  Yeah, I'm familiar with feature flags, but that doesn't really solve the problem of needing well-defined releases and that these releases themselves need to be patched and possibly supported for a long period of time as determined by contract or support commitments. Also feature flags are not going to be able to cover all code changes. For example, it's hard to put code refactoring behind a feature flag. Finally, wide-spread use of feature flags as a type of in-code branch certainly seems like code-smell to me. It's fine for a while, but after 20 years you're going to have a difficult time maintaining that repo unless it's done with sufficient discipline that those feature flags are quickly removed once the feature hits production. It will also screw with your automated static analysis tooling.
  - Aperocky 5y ago
    I think what's missing is the context. When you're a service oriented architecture you can afford these changes. If you're a monolithic block then it gets a lot harder. Personally, I like smaller, well defined changes and CI/CD.

by rsj_hn 5y ago

Aperocky 5y ago

But that's what I'm describing (I do work for one of the FAANG), all feature work are either ready, or gated by feature flags. With practice, it becomes easier to divide feature work while not cause any existing impact, it also forces you to make your code logic cleanly separated. The biggest benefit of this approach imo is the drastically reduced chance of a bad feature going out because someone had worked on it for 5 months in isolation and it becomes virtually impossible to debug.

rsj_hn 5y ago
Yeah, I'm familiar with feature flags, but that doesn't really solve the problem of needing well-defined releases and that these releases themselves need to be patched and possibly supported for a long period of time as determined by contract or support commitments. Also feature flags are not going to be able to cover all code changes. For example, it's hard to put code refactoring behind a feature flag. Finally, wide-spread use of feature flags as a type of in-code branch certainly seems like code-smell to me. It's fine for a while, but after 20 years you're going to have a difficult time maintaining that repo unless it's done with sufficient discipline that those feature flags are quickly removed once the feature hits production. It will also screw with your automated static analysis tooling.
- Aperocky 5y ago
  I think what's missing is the context. When you're a service oriented architecture you can afford these changes. If you're a monolithic block then it gets a lot harder. Personally, I like smaller, well defined changes and CI/CD.