Using Feature Toggling and IoC in lieu of Branching Code -- Good or Bad Idea?

Question

Our clients get to choose when to upgrade. So, my team literally has to maintain and support dozens of versions of our software product. As you can imagine that results in a lot of branching and merging as hot fixes and service packs have to be propagated across all these flavors. I'm not happy with the situation. The obvious solution is simply not to maintain so many different versions of our product, but that obvious solution is not available to me. So, I'm exploring creative options to lower the team's maintenance work. I'm considering using a mix of Feature Toggling and IoC as a way to implement n-number of versions of our software product. The idea is that I could use a single code base for my product and manage behaviors and features via configuration management. This would be in lieu of having to propagate code across multiple branches. Is this a reasonable approach or am I just trading off one problem for another?

Calibre

Sounds reasonable. You would be trading multiple branches for a single codebase, turning features on and off. Theoretically, you could turn features on or off w/configuration. If you really require different code to run, you could use IoC container w/different code implementations. Your question would be easier to answer if you were more specific in your question, giving examples of your current style vs. a proposed style. – Platino

Thanks RaulG, you summed it up well and leveraging IoC to deal with distinct implemenations is exactly what I had in mind. I'm not sure how to answer your question about styles. The application is over a decade old so it doesn't reflect any single style. I would probably apply the above strategy to reengineered components. It doesn't sound like the proposed strategy is raising any red flags. -- Thanks. – Calibre

Answer 1

That sounds reasonable, in that this would be the way I'd address such a problem in a greenfield environment.

Let's not call it a Feature Toggle, though. As the name implies, a Feature Toggle is an on/off switch, which may not be what you need.

Sometimes, an upgrade also involves changed behaviour in existing features. That implies that you're probably going to need something more sophisticated than an on/off switch.

The Strategy pattern is a more flexible way of modelling variation in behaviour. Each Strategy can represent a particular version of a particular behaviour, and if you don't want the behaviour at all, you can provide a Null Object implementation. In other words, Feature Toggle can be implemented with a Strategy.

You can inject the Strategies into your application kernel using Dependency Injection, and you could make the choice of Strategies configurable via a configuration system. Most DI Containers I've heard about (on .NET and Java) support file-based configuration.

This essentially describes an add-in architecture.

Now, even for a greenfield application, this is no easy feat to pull off. If you have a headless system, it's not that hard, but once you have UI involved, you start to realise that you're going to need to componentise the UI architecture as well, so that you can plug in UI elements via Strategies.

On a decade-old code base, this would be what I'd call an 'interesting challenge', to say the least.

Middlesworth