Update Rhythm

Just like everything, updates need to have a certain rhythm. This rhythm can be organized and predictable, or, more often than not, it can be disruptive and chaotic.

Organized and Predictable

Most software languages have an organized and predictable update cadence, or rhythm. Languages like Java and Node.JS follow a 6 month rhythm. They also follow a yearly rhythm for Long Term Support updates.

Do you have an organized update rhythm for the software you write? There probably is an organized rhythm for releasing new features and bug fixes. But what about what may be generally deemed ‘maintenance’? Do you have a set rhythm for updating the programming language of choice? The framework you build on?

Obviously, this organized and predictable approach is a good way to go. You generally keep up to date with things like performance and security fixes. You rarely get surprised by new broken things. The changes are relatively small, and because of this any problems that are introduced are easier to spot. But this likely isn’t how your team actually operates.

Chaotic

Updates to things like frameworks and languages seem to generally happen in a chaotic way. We wait for a few years before we think about updating. Is the version we are on now still supported, at least in writing? Yes, then why should we put effort into updating it?

Somebody usually has to twist our arm in order for us to actually start an update cycle. The security team has to come with some major holes. Licenses are out of compliance. Support won’t touch our version.

Yet these updates tend to create more disruption than benefit. Bugs are introduced, or uncovered. Customers notice that something seems to have changed, for the worse, when they shouldn’t have noticed anything at all. Add this up with the time it took to actually perform the update, and it just seems like a losing scenario.

So why do we still fall into this hole?

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.