Skip to content

Do No Harm — Did you do harm in your last release?

February 11, 2014

Note:  I originally posted this on WordPress on April 2, 2012 and have updated with some modifications in this refresh…

How many times have you downloaded an update to your latest app or gone to a vendor’s web site and nearly entered a fugue rage state because something that use to work is now broken? How many times have you cursed slower performance that isn’t a simple glitch, but seems tied to the latest release? I know I’ve experienced both; it is very frustrating and every occurrence undermines my confidence in those products and erodes any good will I might feel toward the solution or the vendor. I have to admit that as a software professional I have unfortunately been the cause of this in my own career as a developer. All of my teams have also done so at one point or another.

This is why I adopted a simple golden rule many years ago: Do No Harm.

To me one of the worst sins in software development is to introduce what I like to call a “self-inflicted gunshot wound” in to your product. It hits home once the release is deployed in to production and you start hearing about escalations regarding functionality that use to work. These issues can be both in terms of “you broke it” and “performance now sucks”.

It ruins everything: All that hard work you put in to adding some great new feature is now lost as the customer can only focus on what you broke.

I believe that before any code is pushed in to production the team should be able to answer these questions:
• Will you cause harm in this release?
• Have you broken something that use to work?
• Is performance at least as good as it was in the previous release?

At some point in my career I started asking these standard “Do No Harm” questions at every “Release to Manufacturing” checkpoint meeting. The purpose of these questions were to be very clear in terms of what was important to me–in addition to delighting our customers with “Gee I’d Buy It Just For That!” new features and capabilities I also expect a customer’s confidence in the release not to be undermined by discovering regressions.

When I first started asking these questions I’d get blank stares in return. Over time I started to be assured that everything was okay, but when I asked “How do you know?” I’d get folklore as to why folks believed their answers. Nobody really liked my follow up statement to this “wish it and it will come true” positioning: “Prove it…” Eyes would roll and folks would complain that I was changing the rules to the test; this expectation had never been set by previous leadership and it wasn’t fair for me to ask only at the final checkpoint meeting before a product was released.

They were right–it wasn’t fair that it was being asked only at the very end… At the same time the issue wasn’t with me nor my questions… The real issue was that the teams were not asking themselves these questions throughout the entire software development cycle. I didn’t let this sway me and I kept asking and asking and asking.

Progress! Within just a few months all of my teams began showing me their test coverage over existing functionality (some even with dependency charts that showed where changes were made, the risk those changes posed to other areas of the code, and how those areas had been focused on for regression testing/scripts). They would also come to me with their performance test results such that they had sufficient proof. Did that get rid of these issues in production? Not entirely, but it did greatly reduce them.

The miracle came within about twelve months as the teams began to appreciate how bad regressions really were… With every build many teams now knew the answers well before these final hardening sprints and checkpoint meetings. Some had even decided that as part of their continuous build processes that the appropriate unit test harnesses would execute both regression and performance checks; failing the build where appropriate and becoming a core component of their “Quality Up Front” initiatives.

In the end the teams’ solutions became more reliable and customers were not being negatively surprised. The teams were spending more time adding new features vs. working on emergency patches or spending time catching up with what they had broken in the previous release. All was well in Whoville.

Does your team suffer from self-inflicted gunshot wounds in production? If so, does your team have a “do no harm culture”? If not, is it worth it to start asking these three questions with each and every release? With each sprint? With each code checkin? Try it…it worked for my previous teams; I hope it will work for yours.

Advertisements

From → Quality, Software

Leave a Comment

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

%d bloggers like this: