<< Easier Subtext 1.9.5b Database Maintenance | Home | Amazon Universal Wish List Button >>

The Problem With "Release Early, Release Often"

One of the mantras of agile software development is "Release Early, Release Often" - every time you have a new, working version with fixes and updates, you should put that in the hands of the consumer. It's a great idea - if there's something new the consumer of your product, be they developers or otherwise, could use, make it available.

The problem lies in the reciprocal expectation of the producers of said product that the consumers will instantly be able to take the latest available version. This isn't always a valid expectation and can get in the way of product support.

The happy-path scenario is something like a web application that is deployed in a central location and is consumed by various users. A new version of the web app becomes available, the service host deploys the new version, and the end users immediately have the new features and fixes available to them. When the customers need support, it's pretty safe to assume they're on the latest version.

What happens if the product isn't like that, though? What if it's a framework component like a logging library? In my experience, there's a little more work required as a consumer of a third-party framework component to take the latest version than just "download and go." It might look that way to the folks providing that component, but in larger environments that take third-party components on as dependencies, for every new version that comes out you have to consider:

  • Has the licensing changed? (If so, do we need to run this by Legal to get approval for the upgrade?)
  • Is there any fee associated with taking the upgrade?
  • What are the breaking changes?
  • What got fixed?
  • Were we inadvertently assuming incorrect behavior that has changed?
  • Were we working around incorrect behavior that's now rectified?
  • For .NET dependencies, if it's strongly-named and not installed into the GAC, do we need to add binding redirects to configuration? If so, where?
  • Does the product need to be installed on each developer machine or is it a dependency that can be checked in to the central source code repository and seamlessly updated?
  • If we have to support developers working on different versions of our product at the same time and each of our product versions relies on different versions of the dependencies, how does this change the manner in which developers switch their envrionments from version to version?

...and so on. Just because a new version is out doesn't mean your customer can take it. I, as a customer, have to budget time in the schedule for investigating all of the above, testing the upgrade on a standalone developer system, performing any code changes required to take the upgrade, and synchronizing any updates to the developer environments.

So "release early, release often" doesn't help me much in this scenario, and contacting your support department to ask questions about version 1.2 and you not helping me because the first line of support is to "update to version 1.3 and see if the issue is fixed" is crap. (I understand this line more from open-source/freeware projects than I do if I paid a licensing fee and expect support.)

My message to the "Release Early, Release Often" folks: Remember who your end users are. It's great that you're getting the latest version out as often as possible, but it may not be feasible for your customers to take what you're dishing out as soon as it's available.

posted on Monday, December 08, 2008 12:19 PM | Filed Under [ GeekSpeak ]

Comments

Gravatar # re: The Problem With "Release Early, Release Often"
by Wes Maldonado at 12/9/2008 1:42 PM
I believe release early and often means "make frequent releases to your **onsite customer**".

http://c2.com/xp/OnsiteCustomer.html

The customer can then decide when a product is ready to be released to the public. Making sure that your customers are happy with your release cycle is different than releasing early and often to your onsite customer.
Gravatar # re: The Problem With "Release Early, Release Often"
by Jeremy D. Miller at 12/9/2008 4:50 PM
A.) What Wes said
B.) A solid or even a merely adequate continuous integration usage will eliminate a lot of the risk from changes that you're enumerating


You might look at this from the other way around. If I want to be able to at least make production quality internal releases every week or two, what kind of software engineering and team practices would I need, and work backwards from there.
Gravatar # re: The Problem With "Release Early, Release Often"
by Travis Illig at 12/9/2008 4:55 PM
I'll buy that it's the "onsite customer" and not the end user that's supposed to receive these releases, but I still stand by the idea that the end customer may have more overhead to take the drop than the people doing the release realize or care to appreciate.
Gravatar # re: The Problem With "Release Early, Release Often"
by Lior Friedman at 12/10/2008 12:07 AM
Travis,
I think that basically you are right, as a former developer of such a framework it took us some time to (really) appreciate the cost of adoption some of our customers had.

I really think that this factor should be considered when a company adopt the release often strategy. There's much a developer can do to help with this (e.g side by side installation...)

However theres a catch here, unless you branch each version for bug fixes (which is a hell of an overhead), when a customer using an older version meets a defect the only way to help him is by first upgrading him and then patching over the new version.

so theres a fine line here, although the first line of support should not be to upgrade, ultimately if the customer wants a defect fixed he will need to upgrade first. So maybe as a customer you need to see how the upgrade cost can be minimized in your organization?

(If its a pain do it more often until you get good at it and it doesn't hurt)
Gravatar # re: The Problem With "Release Early, Release Often"
by Travis Illig at 12/10/2008 10:39 AM
There's a difference between "we won't help you until you upgrade" and "the upgrade is what will help you." I agree that customers need to work to minimize upgrade costs in their organizations, but in many cases it can only be optimized so far, particularly in large organizations that thrive on too-much-process. I also believe, though, as you said, that framework developers need to work to appreciate the cost of adoption, which is my main point.
Gravatar # Re: The Problem With "Release Early, Release Often"
by Lior at 12/11/2008 6:33 AM
True but,

Being on the other side I saw 3 different answers which customers tended to see as the same:

1. We wont help you until you upgrade.
2. We think that the defect was fixed in a later version.
3. The defect WAS fixed in a newer version.
1 is totally unacceptable on my book, and usually means that the support team is buying some time hoping the problem will go away. Answer 3 is a common enough scenario which leaves the decision with the customer, he needs to decide if the defect is hurting him enough to upgrade.
The 2nd scenario is somewhat more gray, it can in several cases be a more polite way of saying 1 (we didn't really check but there's a chance that we solved it so lets try this one first) or a more diplomatic way of saying 3 (We really did check it out, and it doesn't happen in the new version, however we are not 100% sure so we cant commit on that).

My point is that both sides need to work, if they want the support to be effective and efficient.
Gravatar # re: The Problem With "Release Early, Release Often"
by Brent at 12/19/2008 10:40 AM
Am I the only pervert here that finds "Release Early, Release Often" funny? ...in a non-dork compuer way?! ;-)
Comments have been closed on this topic.