Patches? We Don’t Need No Stinkin’ Patches?

My friend has a cat named ‘Patches’. She is a sweet, adorable little nugget of goodness. But Patches can be demanding—she needs to be fed, have something cozy to nuzzle up against, and unlike most cats, she actually demands attention day and night. Stick with me, this is going somewhere. I promise. Software, like Patches, is a wonderful thing. It is a living, breathing creature, growing and testing boundaries, branching out in new directions. And every once in a while, an exception is discovered, a bug is identified, or an enhancement is made. Ok, that happens more than just every once in a while. And then these modifications to the ‘core’ product need to be distributed to the customer base. They are bundled up in a periodic ‘patch’ or ‘enhancement pack’ and sent out to customers to accept the changes so that they may benefit from the new and improved version. Back to Patches. Being a semi-independent creature, she may not always garner the attention she deserves. Indeed, she shares many other similarities to software as it turns out. And we need to pay close attention to both, or we risk ending up with some unintended consequences. It can be tricky making sure new software patches are tested thoroughly given potential complexities in our integrated business processes. This process demands a keen attention to detail. Here are some thoughts when considering the application of the latest and greatest from software vendors: Review & Assess the Change:

  • Perform an upfront evaluation of what is contained within the update. These are typically covered in “Release Notes.”
  • Determine if the patch is a ‘Technical’ or ‘Functional’ upgrade, or both.
  • If there is new functionality, does it impact the existing business processes?
  • If the patch contains a ‘bug fix’, is the bug currently impacting the process?
Test the Change:
  • Who will conduct the Unit testing, focused specifically on the new functionality? What will be the measure of a successful test?
  • Who will conduct Regression testing, focused on the integration of the new functionality to the existing environment to ensure no negative impacts? What will be the measure of a successful test?
  • Are there automated testing scripts that need to be updated to address any new functionality?
Manage the Change:
  • Is a sign-off or User Acceptance test required?
  • Will end user training be required to ensure proper use of new functionality?
  • What communication and change management tasks will be required to ensure a smooth installation?
  • Are there other projects that need to be considered/consulted when planning the patch installation?
Often times these processes are managed by the IT or Production Support teams. They may or may not understand the functional implications, so it is important to work together to ensure a complete understanding. The patches might come on a periodic basis, such as every quarter, but may be bundled together into a version upgrade on a more infrequent basis, such as annually or every 18 or 24 months. The review and assessment of the periodic update should take place to ensure nothing critical is being delayed if your organization only updates such patches as full upgrades. So, Patches the cat and patches for software are both our friends. We need to be aware of the possibilities they offer to us to ensure we aren’t missing something that might happen to bring a smile to our face, brighten our day or lighten our load.

Back to Blog

Patches? We Don’t Need No Stinkin’ Patches?

My friend has a cat named ‘Patches’. She is a sweet, adorable little nugget of goodness. But Patches can be demanding—she needs to be fed, have something cozy to nuzzle up against, and unlike most cats, she actually demands attention day and night. Stick with me, this is going somewhere. I promise.

Software, like Patches, is a wonderful thing. It is a living, breathing creature, growing and testing boundaries, branching out in new directions. And every once in a while, an exception is discovered, a bug is identified, or an enhancement is made. Ok, that happens more than just every once in a while. And then these modifications to the ‘core’ product need to be distributed to the customer base. They are bundled up in a periodic ‘patch’ or ‘enhancement pack’ and sent out to customers to accept the changes so that they may benefit from the new and improved version.

Back to Patches. Being a semi-independent creature, she may not always garner the attention she deserves. Indeed, she shares many other similarities to software as it turns out. And we need to pay close attention to both, or we risk ending up with some unintended consequences. It can be tricky making sure new software patches are tested thoroughly given potential complexities in our integrated business processes. This process demands a keen attention to detail. Here are some thoughts when considering the application of the latest and greatest from software vendors:

Review & Assess the Change:

  • Perform an upfront evaluation of what is contained within the update. These are typically covered in “Release Notes.”
  • Determine if the patch is a ‘Technical’ or ‘Functional’ upgrade, or both.
  • If there is new functionality, does it impact the existing business processes?
  • If the patch contains a ‘bug fix’, is the bug currently impacting the process?

Test the Change:

  • Who will conduct the Unit testing, focused specifically on the new functionality? What will be the measure of a successful test?
  • Who will conduct Regression testing, focused on the integration of the new functionality to the existing environment to ensure no negative impacts? What will be the measure of a successful test?
  • Are there automated testing scripts that need to be updated to address any new functionality?

Manage the Change:

  • Is a sign-off or User Acceptance test required?
  • Will end user training be required to ensure proper use of new functionality?
  • What communication and change management tasks will be required to ensure a smooth installation?
  • Are there other projects that need to be considered/consulted when planning the patch installation?

Often times these processes are managed by the IT or Production Support teams. They may or may not understand the functional implications, so it is important to work together to ensure a complete understanding. The patches might come on a periodic basis, such as every quarter, but may be bundled together into a version upgrade on a more infrequent basis, such as annually or every 18 or 24 months. The review and assessment of the periodic update should take place to ensure nothing critical is being delayed if your organization only updates such patches as full upgrades.

So, Patches the cat and patches for software are both our friends. We need to be aware of the possibilities they offer to us to ensure we aren’t missing something that might happen to bring a smile to our face, brighten our day or lighten our load.