“Do No Harm” Shouldn’t Just Apply to Doctors

Primum non nocere is a Latin phrase that means “first, do no harm.” This principle is commonly taught in healthcare. In fact, the Hippocratic Oath, taken by doctors, promises they will abstain from doing harm to their patients. Though the exact phrase “do no harm” isn’t included in the original Hippocratic Oath (contrary to popular belief), the Oath does include a similar expectation of “abstain from all intentional wrong-doing and harm”. In the 19th Century, the English surgeon Thomas Inman, who was a house-surgeon to the Liverpool Royal Infirmary coined the phrase “Practice two things in your dealings with disease: either help or do not harm the patient”.

There are a lot of other professions where “do no harm” should be more emphasized as important to service delivery. For example, food preparation – we’ve read countless stories where food providers have issued recalls because of issues with the food they delivered. A common example is the presence of salmonella in meats, vegetables or even peanut butter. Often, the issue isn’t discovered until someone gets sick, or even dies, from salmonella poisoning. Many times, the issue could have been prevented with better safety practices or better training.

Another area where “do no harm” should be considered more carefully (and is the point of this post) is software development. I can’t tell you how many times I’ve worked with a new version of a software product with unexpected changes to the user interface, or with certain features outright broken or removed unexpectedly. While negative changes in software releases aren’t a “life or death” impact, they still cause users to be annoyed or worse – disrupted and missing important deadlines.

I’ve seen it happen with software platforms across the board, including many times eDiscovery software platforms. However, I will use two non-eDiscovery examples I’ve experienced recently to illustrate my point with companies that are frequently changing their interface (no need to shame any eDiscovery developers here).

• Facebook: In their metamorphosis to Meta Systems (see what I did there?), Facebook has made frequent changes to break out personal and professional profiles into separate areas, with separate paths to get to them. Oddly, some steps I need to take with my professional posts still reside in the personal profile, forcing me to toggle back and forth between the two to publish a post and then share the link. That doesn’t seem well planned out.
• WordPress: While WordPress is a great platform for hosting web sites (and is where eDiscovery Today is hosted), they are regularly making changes to the interface for creating blog posts that create confusion and disrupt workflows. For example, they’ve changed the process of changing font colors several times and it has gone from a two-step to a four-step process (who thought that was a good idea?). One recent change took away the form that I used to use to set up guest authors (I had to chat with their Support team to get access to the old form). Another recent change messed up the categories I assign to posts. Those last two changes cause me delays in getting posts out on schedule.

In both cases, these changes came unannounced (at least no announcement that I saw), which was annoying when I attempted to complete normal processes, only to find that I had to figure out how they changed and change the steps accordingly.

Here are three things that software developers should do when rolling out new features to “do no harm” with their customers:

1. Get User Feedback Before Designing Changes: Many software developers live in a “bubble” of understanding the functionality of a given feature, but they often don’t understand how that feature fits into users’ workflows and how disruptive change can be. While feature changes are necessary to continue to improve the software platform, some changes can cause more harm than good. While some users don’t like any change, some changes are necessary. If the feature change must be implemented to propel the product forward, getting user feedback beforehand will at least give them a heads up that the change is coming, instead of being surprised when it’s there.
   
   When I worked with Bill David at CloudNine, he used to tell customers that “we eat our own dog food” (which always made me chuckle) regarding the fact that we used our own software to provide services as well and had that user perspective. The more you can understand the mentality of your customers in using your product, the more likely the software changes you implement will be positively received.
   
2. Focus More on Product QC: Every development team has a corresponding QC team, but it’s been my experience that some companies place less skilled people into those positions, and they aren’t as thorough as they should be. They may focus well during system testing on ensuring a new feature works properly, but not enough to ensure that the changes don’t break other existing processes. Staff your QC team with people at least as qualified to support the software development process as the developers and other professionals in the process. Nothing shatters the good will of new functionality like user discovered software bugs.
   
3. Document and Communicate: Every feature release, no matter how small, should include release notes (with screen shots to illustrate changes) to let the users know what’s changed and how it impacts them. And awareness of those release notes should be communicated to users, with a link to them made available in a prominent place. For larger releases, a beta release is appropriate to enable users to test features before they are rolled out and provide feedback on issues they encounter. There should be a mantra of “no surprises” when implementing new features.

There should also be a mantra of “do no harm” when implementing software changes. Sure, it’s not a “life or death” situation like it is with doctors, but if you keep doing harm when rolling out new features, it could lead to the slow death of your software platform.