4 ms·

"we developed a new way of developing software using if statements instead of branches." Is that critizing feature flags? Or is more to that?

axod 17y ago
It often makes sense to have 2 alternate implementations of a component in the same codebase, so you can switch between them at startup/during runtime, and compare them side by side. Something that isn't as easy to do if you create 2 separate branches.
- etherealG 17y ago
  I think a better solution is to have both features in branches, and have a 3rd branch which allows realtime switching between the 2. a nice upside is that you can merge changes to each feature up into the "combined" branch as they get stable, to test side by side. when you finally finish, you can leave feature a behind by merging b into your release, or vice versa. or maybe even merge both into mainline. sorry, the point I was trying to make is that cheap branching and merging is still an easier way to manage this situation than just ignoring branches altogether.
  - axod 17y ago
    In what way easier? A: Create separate branches, manage merging/updating unrelated changesets. B: Create 2 implementations of something in code, and manage nothing. I guess it depends on how easy it is to isolate the part you want to create 2 implementations of, so it may depend on what language you're using as well as how you architected things. Branching+Merging just seems like something extra I have to do, manage, and remember. Like filing. And I still can't see what benefit it gives for many cases. But that's fine I think... I just don't get it. Maybe I'm too old ;)
- barrkel 17y ago
  Well, if you have a well defined protocol / interface for your component, and you have a runtime versioning mechanism (something as simple differently named DLLs will do if you're at the C level), then you ought to be able to do both: put the new code in a separate branch, but still switch in the old code at runtime. An advantage of keeping an old code in its own branch is that it's less likely to become incompatible through random changes. In particular, I'm thinking of bug compatibility: there may be bugs you wish to fix in the new code, but you don't want to fix in the older code because of third-party dependencies.
- jrockway 17y ago
  Indeed. It's a very common pattern to "has a" something that does some role, and then provide varying implementations. Image::PNG, Image::JPEG; Logger::File, Logger::Syslog, Logger::Database, Logger::Email, etc. This may give you millions of combinations, but since the various parts that don't need to interact can't interact, this isn't really a problem. OOP is nice when used by people that know OOP.
spolsky 17y ago
Feature flags are usually just a poor-man's way to separate development (changing) and live (stable) code branches. They have explosive complexity (2^n combinations need to be tested). They require you to contort your code unnaturally to minimize the number of conditionals.
- jedbrown 17y ago
  Compile-time choices are a terrible code smell. If object creation is sorted out (through dependency injection/service locator/etc), the compile-time choice can usually map to exactly one runtime option and exactly one conditional.
  - raganwald 17y ago
    Exactly. You're already creating all your objects with factories, so all you have to do is build a FactoryFactory that builds the right kind of factories and you're good to go... http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://discuss.joelonsoftware.com/default.asp?joel.3.219431
    - jedbrown 17y ago
      While that's a classic and amusing essay, having client code depend on concrete types instead if interfaces is lame unless you can be confident that they won't change their mind about which one they want to work with. I write mostly C, don't have anything called a factory, and yet every major object has a plugin architecture, many of these have more than a dozen implementations, and client code automatically works with all of them (and any that they or a third-party have written). Say what you will about architecture astronomy, but this is not complex and is far more maintainable and usable than the alternatives.
      - raganwald 17y ago
        I'll take it one further and suggest that the expression concrete type is an oxymoron and that there are many, many ways to decouple code. You've mentioned two orthogonal ways to achieve this goal: Programming to interfaces (most people use this term to mean collections of method signatures) and Plugin Architectures (which sounds a lot like using composition or strategies instead of implementations). But I stand by the tongue-in-cheek suggestion that FactoryFactories are high altitude if not low earth orbit. And obviously, you can use factories and still switch between production and development with a single flag. So please don't interpret my remarks as critical of code I've never actually seen.
nfnaaron 17y ago
What he's talking about is branching in code to avoid all subversion branches. That's probably pathological.

axod 17y ago

It often makes sense to have 2 alternate implementations of a component in the same codebase, so you can switch between them at startup/during runtime, and compare them side by side. Something that isn't as easy to do if you create 2 separate branches.

etherealG 17y ago
I think a better solution is to have both features in branches, and have a 3rd branch which allows realtime switching between the 2. a nice upside is that you can merge changes to each feature up into the "combined" branch as they get stable, to test side by side. when you finally finish, you can leave feature a behind by merging b into your release, or vice versa. or maybe even merge both into mainline. sorry, the point I was trying to make is that cheap branching and merging is still an easier way to manage this situation than just ignoring branches altogether.
- axod 17y ago
  In what way easier? A: Create separate branches, manage merging/updating unrelated changesets. B: Create 2 implementations of something in code, and manage nothing. I guess it depends on how easy it is to isolate the part you want to create 2 implementations of, so it may depend on what language you're using as well as how you architected things. Branching+Merging just seems like something extra I have to do, manage, and remember. Like filing. And I still can't see what benefit it gives for many cases. But that's fine I think... I just don't get it. Maybe I'm too old ;)
barrkel 17y ago
Well, if you have a well defined protocol / interface for your component, and you have a runtime versioning mechanism (something as simple differently named DLLs will do if you're at the C level), then you ought to be able to do both: put the new code in a separate branch, but still switch in the old code at runtime. An advantage of keeping an old code in its own branch is that it's less likely to become incompatible through random changes. In particular, I'm thinking of bug compatibility: there may be bugs you wish to fix in the new code, but you don't want to fix in the older code because of third-party dependencies.
jrockway 17y ago
Indeed. It's a very common pattern to "has a" something that does some role, and then provide varying implementations. Image::PNG, Image::JPEG; Logger::File, Logger::Syslog, Logger::Database, Logger::Email, etc. This may give you millions of combinations, but since the various parts that don't need to interact can't interact, this isn't really a problem. OOP is nice when used by people that know OOP.

spolsky 17y ago

Feature flags are usually just a poor-man's way to separate development (changing) and live (stable) code branches. They have explosive complexity (2^n combinations need to be tested). They require you to contort your code unnaturally to minimize the number of conditionals.

jedbrown 17y ago
Compile-time choices are a terrible code smell. If object creation is sorted out (through dependency injection/service locator/etc), the compile-time choice can usually map to exactly one runtime option and exactly one conditional.
- raganwald 17y ago
  Exactly. You're already creating all your objects with factories, so all you have to do is build a FactoryFactory that builds the right kind of factories and you're good to go... http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://discuss.joelonsoftware.com/default.asp?joel.3.219431
  - jedbrown 17y ago
    While that's a classic and amusing essay, having client code depend on concrete types instead if interfaces is lame unless you can be confident that they won't change their mind about which one they want to work with. I write mostly C, don't have anything called a factory, and yet every major object has a plugin architecture, many of these have more than a dozen implementations, and client code automatically works with all of them (and any that they or a third-party have written). Say what you will about architecture astronomy, but this is not complex and is far more maintainable and usable than the alternatives.
    - raganwald 17y ago
      I'll take it one further and suggest that the expression concrete type is an oxymoron and that there are many, many ways to decouple code. You've mentioned two orthogonal ways to achieve this goal: Programming to interfaces (most people use this term to mean collections of method signatures) and Plugin Architectures (which sounds a lot like using composition or strategies instead of implementations). But I stand by the tongue-in-cheek suggestion that FactoryFactories are high altitude if not low earth orbit. And obviously, you can use factories and still switch between production and development with a single flag. So please don't interpret my remarks as critical of code I've never actually seen.

nfnaaron 17y ago

What he's talking about is branching in code to avoid all subversion branches. That's probably pathological.