Beyond Bugs: Reimagining Software Development Through the Lens of Insufficiency

It's time to re-frame how we think about software problems that surface “in the wild” – that is, after the software is available and in “production” use. What if we stopped describing signals from our customers with reference to the development process, as bugs vs enhancements? What if instead we thought of all issues raised about released software from the customer perspective? Maybe it's time to shift to an insufficiency frame.

The “bug” frame centers figuring out what's wrong. The insufficiency frame directs our attention toward a better future for our customers, our products, our companies, and ourselves. If we can take something that's insufficient and make it adequate we've stepped onto a path that leads to ongoing improvement in products that will inspire customer trust, have a durable and sustainable market life, and enable users to work with confidence, efficiency, and effortless enjoyment.

Bugs, Blame, and Bureaucracy: The Unsustainable Status Quo

Support agents, product managers, and developers sometimes struggle to categorize user feedback as bugs or feature requests. This categorization process can lead to inefficiencies:

The root cause analysis often devolves into determining fault:

This approach can create a negative culture where:

Embracing Insufficiency: A New Framework for Software Problem-Solving

What if we just didn't do this anymore? We could instead consider these contacts as a signal of insufficiency, no different from signal we gather by our outreach or research.

There are all kinds of ways that an application in production use can be completely sufficient in some, maybe most, situations or purposes yet insufficient in others. These departures from adequacy could cause a wide range of actual, perceived, trust, or reputation harms, regardless of when, how, or why these situations came to exist.

Let's look at some of the several types of insufficiency, some examples, and how treating all requests as a single stream makes sense no matter the nature of the insufficiency. In the varieties and examples below some would are more severe and need a solution more urgently. On the other hand, some might not be part of our strategic vision or just won't rise to the top of the stack as we prioritize work.

When we handle these in a single stream we give ourselves the best chance to improve both the software and the product. We can offer our top priorities to development, describing their significance and urgency. And we can leave it to the development organization to provide technical services that can address prioritized requests at the needed level of urgency.

Varieties of Insufficiency
1. Functionality
2. Usability
3. Performance
4. Compatibility
5. Support
6. Security
7. Customization
8. Reliability
9. Integration
10. Cognitive Load
11. Feedback
12. Aesthetics

Insufficiency Examples
* crashing frequently
* failing to perform core tasks correctly or adequately
* missing expected capabilities
* hard to use
* unpleasant or displeasing sensory characteristics
* perception that it's too slow
* unintuitive interface
* limited cross-platform support
* documentation and help resources are incomplete, obsolete, or available in a dated format
* desired flexibility or customization options aren't available
* desired APIs or extensibility options aren't available
* poor error messages

Process implications of adopting the “Insufficiency” frame

Once we make this shift we'll never again have—at the tech-business or company-customer boundary—a discussion of whether development will identify the issue as a bug, defect, change, enhancement request, new feature, or anything else.

Instead, we'll have a single queue to prioritize by its customer impact, and the impact on our business—but not by the way a developer might categorize it.

But won't this mean developers will spend all their time on fixing problems and never be able to accept new work that improves our product? No! Here's why:

Benefits of the Insufficiency Mindset

I believe there are several benefits to be gained by the organization that can make the shift away from “bugs” to “insufficiency.” I don't have empirical data—I don't know of a company that has adopted the “insufficiency” frame—but based on my experience I believe it's possible to realize benefits like these:

Conclusion

Can we shift from a deficiency to an insufficiency mindset? If every request is a signal of insufficiency, and we no longer try to assess whether the request represents a bug, enhancement, or feature request, we can streamline internal processes and improve software development efficiency.