Inconsistency in upgrading

As you may have noticed, most things these days like to upgrade themselves over the internet, which means for some products (or worse your box) an unexplained slowdown as they download that other bugfix/servicepack/upgrade.

It has to be said that for Architecture as a whole, together with the Source Control, Project Development/Delivery and Infrastructure Policies, this is one to sort out before the code is even started. While the Agile community may want to code from day one, the truth is that these type of activities, whilst not being coding, will save you much time, pain and money down the line if you get them “right”.

Well, I say “right”, let’s be honest, we aren’t perfect, but we should know our business, right ? In this sense our update/upgrade policy should match. If you want examples, there are plenty out there:

For my money, my current model to follow would be Steam. It’s transparent enough so you know what is happening, granular enough to control it, and CONSISTENT.

That last point in particular, it’s annoying to find out about major updates to programs on systems that supposedly update, such as the “Live” products from Microsoft, via other routes; in the same way as it’s not much fun to find updates that are allowed to reboot your box without telling you.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s