Friend or Foe? Examining the Pros and Cons of Feature Toggles and Trunk-Based Development

My experience at ThoughtWorks , a pioneer in Agile development, exposed me to “sensible defaults ” — a set of best practices that ensure efficient software delivery. Two of the most impactful practices I learned are Feature Toggles and Trunk-Based Development (TBD). These approaches are considered foundational to ThoughtWorks’ methodology due to their effectiveness in streamlining development and enabling rapid iteration.

Although TBD is somehow debatable, even within ThoughtWorks, there is no double that it delivers lots of benefits when used in the right project with proper implementation.

In this blog, I’ll discuss Feature Toggles and TBD, their benefits, and when they should and shouldn’t be used.

What is a feature toggle?

Feature Toggles (often also refered to as Feature Flags) is a technique, allowing teams to modify system behavior without changing code.

Feature toggle allows specific features of an application to be activated or deactivated at will. This allows developers to safely “toggle” new features on or off for testing. Feature toggles have many use cases beyond testing, such as the targeted rollout or quick rollback of new features in production, experimentation, canary releases, operations, or activation of premium features.

Feature Toggles complement Trunk-Based Development by safely integrating incomplete features into the main branch. This way, the main branch is always in a deployable state, and teams can work on features without long-lived branches.

Example

Let’s consider a simple .NET Core application where we want to toggle a new feature.

Setting up the Feature Toggle

First, we define a feature toggle service. For simplicity, we can use a configuration-based approach.

// IFeatureToggleService.cs  
public interface IFeatureToggleService  
{  
    bool IsFeatureEnabled(string feature);  
}

// FeatureToggleService.cs  
public class FeatureToggleService : IFeatureToggleService  
{  
    private readonly IConfiguration _configuration; public FeatureToggleService(IConfiguration configuration)  
    {  
        _configuration = configuration;  
    } public bool IsFeatureEnabled(string feature)  
    {  
        return _configuration.GetValue<bool>($"Features:{feature}");  
    }  
}

Configure and use the Feature Toggle

In appsettings.json, we add our feature flags.

{  
  "Features": {  
    "NewFeature": true  
  }  
}

Here, we store the feature toggle setting in the config file for simplicity. In real-world projects, it is recommended that the settings be stored in a database. By storing the feature toggle settings in the database, you can change the state of a feature (on/off) and see those changes reflected instantly within your application.

This is particularly important because it allows product owners and stakeholders to have instant control over the visibility of new features, enabling them to be showcased and explored in isolation before being released to production users.

To use the feature toggle service is as simple as injecting the feature toggle service and an if statement, as in the example below.

 public HomeController(IFeatureToggleService featureToggleService)  
    {  
        _featureToggleService = featureToggleService;  
    } public IActionResult Index()  
    {  
        if (_featureToggleService.IsFeatureEnabled("NewFeature"))  
        {  
            ViewBag.Message = "New Feature is Enabled!";  
        }  
        else  
        {  
            ViewBag.Message = "Welcome to our website!";  
        } return View();  
    }  
}

When Not to Use Feature Toggles

While feature toggles offer flexibility, they shouldn’t be a permanent solution. Here’s when to consider alternatives:

• Core Functionality: Don’t toggle essential features that define your application’s core behavior.
• Complex Logic: Avoid intricate logic based on toggles, which can lead to maintenance headaches.
• Short-Lived Features: If a feature is very short-lived or experimental, the overhead of adding and managing a toggle might not be worth it.

Trunk-Based Development

Trunk-based development (TBD) is a source-control branching model in which developers integrate small, frequent changes into the main branch (trunk). With trunk-based development, your team integrates changes directly into the main branch (trunk), whereas other branching strategies like GitFlow involve integrating into multiple feature branches.

TBD doesn’t mean we completely ditch feature branches. Instead, these branches are kept short-lived. We can still use them for code review, merge requests, and branch builds to get quick feedback. The key difference is that you avoid long-lived branches like release branches.

TBD and feature toggles are complementary practices used in Agile development. We can use feature toggles in development without adapting TBD, but they are often combined together, as the feature toggle is a must-have tool for TBD.

Prerequisite for TBD

Trunk-based development can be a very efficient and powerful tool only if the team meets the conditions below:

• A capable team with a high level of trust between the members. TBD often works well with a small and skillful team. It is key to have a strong dev team. Without it, the TBD will cause more harm than good.
• Automated unit and integration testing in place with good test coverage.
• A solid CI pipeline

Implementing trunk-based development without those is a recipe for disaster. The common symptoms include frequent broken builds and code churn.

Some can argue that the benefits of Trunk-Based Development (TBD) are more a result of its prerequisites, like good unit test coverage, rather than TBD itself. This argument is not wrong. However, TBD acts as a framework that enforces practices like good test coverage, continuous integration, early feedback, and clear communication. These practices, in turn, create an environment where good unit test coverage flourishes and delivers its benefits.

TBD only works with a strong team

The success of trunk-based development hinges on a strong, well-coordinated team. Without a culture of clear communication, mutual respect, and a willingness to learn from each other, especially for less experienced developers, the challenges of trunk-based development can quickly become overwhelming.

The clear communication between teams is essential. The team members must talk openly to fix problems quickly and share any changes affecting the main codebase (trunk).

Another good practice that complements TBD is pair programming. As developers work together, code reviews become part of the development process. This allows for immediate feedback, early bug detection, and knowledge sharing. However, to avoid burnout, pair programming should be an opt-in approach. Developers should choose when collaboration can be most beneficial.

Conclusion

Feature toggles and trunk-based development empower developers to deliver features faster and more reliably. By understanding their benefits and limitations, we can leverage them effectively to streamline our development process and deliver faster and more frequently.

Remember, feature toggles are for temporary control, not a long-term architectural solution. In other words, don’t forget to remove the feature toggle in the end! Use them wisely to keep your application on the cutting edge.