Need an extra set of eyes?

Paul Gibbons suggested in the introduction to Part One of The Science of Successful Organizational Change that every generation thinks it’s path is shaped by great upheavals.  Much of this perception is due to availability bias. Availability bias leverages the most relevant immediate example to evaluate a concept or idea.  The availability bias is only one of a myriad of cognitive biases that humans have developed to deal with the complexity of the world around us.  Steven Adams recently asked, “What biases/fallacies might a developer fall prey to when testing code that he or she developed?” If we broaden the question to which of the cognitive biases would affect anyone reviewing their own work (based on the 16 we have explored over the past two years), there are several cognitive biases that would suggest that reviewing your own work is less fruitful than getting a different set of eyes.  Some of the leading culprits are: (more…)


How to Measure Anything, Finding the Value of “Intangibles in Business” Third Edition

Chapter 8 of How to Measure Anything, Finding the Value of “Intangibles in Business” Third Edition, begins the third section of the book.  Part III is focused on Measurement Methods.  Chapter 8 is titled, The Transition: From What to Measure to How to Measure. This is where you roll up your sleeves, crack your knuckles and get to work. Whenever you are beginning something new, the question of where to start emerges.  If I were to summarize the chapter in three sentences I would say: (more…)

Call them bunnies or opportunities or whatever...

Call them bunnies or opportunities or whatever…

Every once in a while the person sitting next to me on a flight home works in IT. We generally trade war stories, the human version of dogs meeting on the street.  Recently a seatmate described an environment in which defects and production problems had been renamed as opportunities. Discovering opportunities was considered to be a positive and the organization seemed to have a lot of them.

Every profession has a common language and that language tends to be built into common processes and frameworks.  Common industry language generates a specific behavioral bias. Testing and software development are no different. The product of software development, enhancements and maintenance activities is software. In development and testing, stuff that goes wrong are typically called errors, defects and failures.  Each has an industry standard meaning.

Errors can be generated by human and external factors. In most IT departments human factors are the most significant source of errors because humans write software. People make mistakes for reasons ranging from the complexity of the business process to distractions caused when someone in the next cube spills coffee on their lap. The bottom line is that we make errors that produces an incorrect result. Calling mistakes opportunities or something else with a similar positive spin changes the behavioral bias from something to avoid to something to to embrace.

Errors can translate into defects (also known as bugs). In software, defects are a flaw that can cause the code to fail to perform as required. As noted in the Principles of Testing, not all defects are discovered or ever occur.  I have spent more than a few nights pouring over code that had not been changed in years only to finally be exposed to a strange set of conditions that had never been seen before. Many years ago I was working for a credit card processing firm that discovered that if the same person bought the same item costing 99 cents, 100 times in a row using a credit card our file maintenance system would fail spectacularly.  Finding and fixing that bug funded at least one coffee plantation.

Defects that occur when the code is executed and represent a difference between what the application is supposed to and what actually happens are termed failures. The code in the credit card file maintenance system was a defect that existed for several years before the fateful night that someone ordered 100 99-cent items on The Home Shopping Network at 1 AM (what was even more strange was that the same person did the same thing the next day at approximately the same time). As soon as the defect actually happened, it became a failure.

Mistakes, defects and failures, whether generated by human factors or external factors (e.g. pollution, radiation or a Super Storm Sandy), are in some sense opportunities to learn and refine how we practice our profession. During the Software Testing Foundations class I recently took, the theme of avoiding the use of  industry standard definitions because words like mistakes, defects and defects can cause poor behavior (e.g. defect hiding, pointing fingers or team strife).  Dawn Haynes, the class instructor and industry consultant, recounted a story of an organization that once called defects and failures “bunnies” in an attempt to avoid negativity. Like my seatmate’s company, they found that they had lots of bunnies and finding and removing bunnies was not taken very seriously. Renaming mistakes, defects and failures to opportunities or bunnies trivializes the efforts of everyone that spend time reviewing, testing and monitoring software execution. I would rather focus my creativity of learning and improving how value is delivered than finding neutral or happy terms to describe errors, defects and failure.