Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version

As software creators we don't get to decide what version of our tools / libraries that people use. If we try to force them, our users will go somewhere else.

Update: What Type of Software This Applies To

This post talks of tools, applications and libraries. Things that end up in the users hands. This does not apply to SaaS or websites. These do not end up in the hands of the users in the same sense.

For those of you who immediately think of Chrome or Firefox, which are applications that end up in the users hands, those apply to this post as well. They have nearly perfected a silent upgrade experience, but if they ever mess up that experience, users can choose to use something else. And I believe there is a way to opt out as well (not easily achieved but possible).

Software Release Management

I write software. Much of it is open source. I have multiple versions of my products out there. Even with newer versions available that fix bugs and bring about new features, I still find people using older versions. Even though I have a better newer version that fixes some of the bugs they are dealing with, they are still using an older version. Think about that for a second. There must be a good reason right? Let’s state this in an official sense.

As a software creator you release software. You put a release out there and people use that release. You delineate different releases by a concept of versioning. People use a particular version of your release. You release newer versions of your software that has fixes and enhancements. You hope users upgrade to the latest release when it is available.

I’ve stated five facts and finished with a hope. If you can accept those as facts, we can move on. If we can’t, then you might want to stop reading now because we are never going to agree. If you are a developer like me, you really want people to always use the latest version of your software, so you might be able to accept the last statement as a fact for you. I really want people to always use the latest release of my software as I have went through the trouble of testing it and making it better.

Now let me change some terms for you. Software release management is really a fancy way of saying package management. A software release could be better termed a package. So to restate, as a software creator, you release packages. You put a package out there and people use that package. You delineate different packages by a concept of versioning. People use a particular version of your package. You release newer versions of your package that has fixes and enhancements. You hope users upgrade to the latest package when it is available.

The Hope Versus The Force

I say “hope they upgrade” because you really can’t control that aspect. You can try. You can delete the older versions. You can refuse to have older versions available. You can tell users that they should and need to upgrade. But you put it out there once and it is now out there forever. People will find a way to get to the particular version they need. Or they will go elsewhere. Users speak with their feet.

I find attempting to force a user to do something is both an exercise in futility and a great way to guarantee that you have less users overall.

So people must want to use a particular version of a product. Let’s examine this a little more. Why on earth would someone use an older version of a product when a newer, better, less buggier version is available?

Why Do Users Use Older Versions?

Users use older versions of our packages and they have great fundamental reasons for doing so:

  • It reduces their risk.
  • It guarantees that users of their library (that has a dependency on your library) have a good experience.
  • It guarantees that the product that they have tested is the same product that gets into the hands of consumers.
  • It guarantee their product builds successfully and the same way each time.

In fixing a product and making it better and less buggier, you may actually be breaking someone’s ability to use a newer version. And you have no guarantee to the user that this version doesn’t have flaws of it’s own. Right? Otherwise there would only be one version that ever had fixes in it. We wouldn’t need to release newer versions with fixes, only enhancements. But we don’t. We fix things we thought worked and we fix things we tested but missed some crazy edge case. This is why we go down this path of release management. This is software development.

So people get a certain version and they use it. Users upgrade to the latest version of software when they are ready, not when the software creator is ready. People depend on certain versions or on a range of versions. In reality I can't force someone to use the latest version. If I try, they will find the version they need through the powers of the internet or find another way. Accepting that, I can give them a way to see it and help them fall into the pit of success.

From the User Perspective

Shifting to the perspective of the user, I might use your library in my own software. Being able to build my product, even if it means it is using an older version of your package that has bugs, is worlds more important to me and my users. We'll get to your latest version when we can test that it doesn't break our product. But don't try to force me to upgrade to your latest version or I will find another way. I'm not saying that with your package but in all packages the newer version may be buggier than the current buggy version we are using. We don't know and you can’t guarantee that it doesn’t, even with extensive testing. Testing doesn’t prove the absence of bugs, only the absence of errors that you know. I digress.

It’s an evil that we know versus and evil that we don’t. Or put another way, it's a buggy version we know versus a buggy version we don't.

If it’s a tool, we need to ensure that our usage of your product still meets our expectations. We need to test it even though you did and make sure it still works for our needs and scenarios. Where it doesn’t we need to decide if that means we can shift our expectations and upgrade. But we are not going to blindly upgrade and just use the latest version because the software creator believes that is best.

Can you cover the millions of dollars that we might lose by taking on a newer version of your product? If you can give me that guarantee, as a user I will gladly pass that risk on to you.

Final Thoughts

Whether you agree or not, as software creators we don't get to decide what version of our tools / libraries that people use. We just don’t have that luxury. If we try to our users will go somewhere else. So we make it easy for them to upgrade so they will want to. We make the upgrade experience painless so they will want to. We need to be good stewards.


Posted 01-25-2012 10:29 AM by Rob Reynolds
Filed under: , , , ,

[Advertisement]

Comments

Rob Reynolds wrote re: Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version
on 01-25-2012 11:48 AM

Of course this doesn't apply to websites and SaaS. But then again, they don't have releases in the same way.

Marcus Swope wrote re: Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version
on 01-25-2012 11:54 AM

I think it would be useful to articulate what kind of software you are talking about. I just saw your comment after reading through the whole post and thinking to myself of all the great examples we have of software that DOES force users to upgrade to the newest version (Chrome, Firefox, Facebook, every single website and most SaaS solutions, etc...).

In your comment you said that websites and SaaS don't have releases in the same way. The same way as what? I'm confused what type of software it is that you are actually talking about.

Rob Reynolds wrote re: Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version
on 01-25-2012 11:59 AM

@Marcus: Good point - in this context I am thinking of libraries and tools/ applications. Things that you bring local to your system. I'll update the post.

First time Chrome or Firefox breaks my experience with their silent updates, I can move on to another product. I can still speak with my feet.

Erik wrote re: Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version
on 01-25-2012 12:11 PM

I agree with the sentiments in this post completely.  For me, when producing software, it's kind of the Golden Rule.  I frequently get a version of something, either as a library to use in my own code or just as a tool, and have no interest in upgrading.  If it works perfectly for me as-is, there's risk associated with that, but no benefit, so why do it?

And, given that attitude, I tend to sympathize with users of software that I write.

Harry M wrote re: Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version
on 01-25-2012 2:14 PM

It applies to web application APIs, unless you are going to break all your user's client applications...

...unless you have the rarely-seen HATEAOS REST API and people have written the even more mythical ContentType versioned, HttpStatus aware, link rel following magical self adaptive web client*.

*AKA your user accessing your API via Firefox

Dan Puzey wrote re: Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version
on 01-26-2012 6:21 AM

Chrome, Firefox & co. are only good examples because they haven't broken anything yet.  At some point there will be cause for frustration that you can't get back to Chrome 26 when Chrome 27 has broken something, or even just changed it for the worse.

I'm sure a lot of people would still be using 2-year-old Facebook, given a choice...  For websites I'd argue that the only reason this applies less is *because* you can force an upgrade on users.  That doesn't mean they won't vote with their feet too, but at least you know that your remaining users are on your newest package!

A further extension of the concept is that, in many cases, what is deemed "buggy" behaviour might be essential for the successful operation of a product.  If there's a minor bug in an API that's otherwise critical, consumers will build their product to work around it.  Even a genuine "fix" to that behaviour might well break the code built on it.

Which also highlights that this isn't just about *local* things, but about anything that you might consume... a web services API, for example, will come under this rule to some extent.

Chris Marisic wrote re: Software Release Management - Why You Can’t And Shouldn’t Force People to Use the Latest Version
on 01-26-2012 4:32 PM

This is why I choose to develop targeting web applications.

There is no choice in upgrade. You use the current version of our service, or you don't use our service.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)