Long-Running Branches and the Agile Way
Recently I've been thinking a bit about long-lived branches and the affects they have both on the software and the value they bring to the company. I've read a number of great articles about long-lived branches (such as this one) that do a great job explaining the reasons against them. I've also read a few in favor of long-lived branches the do a good job explaining the perceived benefits of this practice.
One thing I think these articles fail to mention is the impact long-lived branches have on business value. Not only are long-lived branches inventory and shipping to the customer, they're depreciating. They're sitting on the shelf depreciating. One day, when you want to add it to the rest of the software, there will be a lot of work integrating it back in. Or you might spend a lot of time keeping that branch in sync.
The main argument I hear for long-lived branches is that it reduces the complexity of the code. Instead of implementing a feature flag which would require the introduction of one or more if-statements, the code is branched. While it does keep the main line of code cleaner, it defers a lot of work til later in the development cycle. As a result, they end up introducing a lot of waste in the form of time spent keeping the branch in sync with the main line.
As we consider that point, we might be prone to jump into feature flags. Now, there is a time and a place for feature management at this level, but I'd submit that even feature flags are an indication of a failure to follow agile principles. Agile says the primary measure of success is working software, but what good is the software if it isn't in customer's hands? Agile encourages the development teams to think in the form of Minimum Viable Products and to release such increments early and often. Why is that desirable? So that you know you're building what your customers need instead of what you think they need.
The sooner a feature is released, the sooner customers can experience it and offer feedback on it. Do customers love the new features? You won't know until they can try it out. What would customers change or improve about the software? You won't know unless they're able to use the software. You might have an agenda or a vision for the software, but is that what the customers really need? You won't know until they're using the software. Thus, releasing early and often is a key tenant of Agile Software Development.
Overall, both long-running branches and feature flags introduce waste and a cost to the company. While I'd argue the cost of long-running branches is greater than that of feature flags, they're both sub-optimal in the world of agile development. The preferred way is to identify the smallest releasable chunk of work and to get that in customer's hands. That will generate feedback that the team can then iterate on. This way provides more value to the customer and to the company.
One thing I think these articles fail to mention is the impact long-lived branches have on business value. Not only are long-lived branches inventory and shipping to the customer, they're depreciating. They're sitting on the shelf depreciating. One day, when you want to add it to the rest of the software, there will be a lot of work integrating it back in. Or you might spend a lot of time keeping that branch in sync.
The main argument I hear for long-lived branches is that it reduces the complexity of the code. Instead of implementing a feature flag which would require the introduction of one or more if-statements, the code is branched. While it does keep the main line of code cleaner, it defers a lot of work til later in the development cycle. As a result, they end up introducing a lot of waste in the form of time spent keeping the branch in sync with the main line.
As we consider that point, we might be prone to jump into feature flags. Now, there is a time and a place for feature management at this level, but I'd submit that even feature flags are an indication of a failure to follow agile principles. Agile says the primary measure of success is working software, but what good is the software if it isn't in customer's hands? Agile encourages the development teams to think in the form of Minimum Viable Products and to release such increments early and often. Why is that desirable? So that you know you're building what your customers need instead of what you think they need.
The sooner a feature is released, the sooner customers can experience it and offer feedback on it. Do customers love the new features? You won't know until they can try it out. What would customers change or improve about the software? You won't know unless they're able to use the software. You might have an agenda or a vision for the software, but is that what the customers really need? You won't know until they're using the software. Thus, releasing early and often is a key tenant of Agile Software Development.
Overall, both long-running branches and feature flags introduce waste and a cost to the company. While I'd argue the cost of long-running branches is greater than that of feature flags, they're both sub-optimal in the world of agile development. The preferred way is to identify the smallest releasable chunk of work and to get that in customer's hands. That will generate feedback that the team can then iterate on. This way provides more value to the customer and to the company.
Comments
Post a Comment