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:
- Microsoft’s BITS system for Office and Windows
- Adobe’s background service
- Firefox who downloads while you run the browser (it’s really hard to find a proper link for that, anyone help me out ?)
- Steam – who acts as housekeeper for all the products on it’s delivery.
- iTunes – similar to Adobe
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.