Rumination on High Quality Software

The cost of software quality is either prepaid or postpaid, the price must be paid eventually, one way or another.

Often, I get asked why we have a high-quality bar in my teams, and why it matters.

Here are my top Why’s

1. Deliver value to customers: The customer is the most important stakeholder to whom we deliver value. Without at least 1 customer to serve, what we build and operate is meaningless, and to provide a service that can be trusted and return to get their job done, we must provide a value that is not found anywhere else.
2. Uphold team wellbeing: Burnout is a consequence of excessive unplanned work in progress. Remember the Quiet Quitting.
3. Anticipate & prevent reactive work: Teams have planned (proactive) work and unplanned (reactive) work. When the software quality is perceived to be low or buggy, slow, or unpredictable; the quantity of unplanned work is relatively higher, and hence impacts team focus on future work. Adopt the 5S method.
4. Proactively manage perception: 100 great things delivered would have changed the lives of customers, however, it takes one wrong thing to diminish the value of 100 great things done. The perception of the team degrades internally and externally, and everyone and everything the team does is under scrutiny, which in turn, takes the precious team's time away from planned work. Remember the Boeing 737 MAX groundings.

Methods to improve quality, day 0 onward

1. Customize the quality pyramid, follow a simple software quality pyramid with 3 levels to ensure adequate customer-focused scenarios are covered during unit tests, integration tests, and end-to-end tests.
2. Deliver value/impact, Metrics may be fudged, but focusing on value and impact is great for customer onboarding and customer journey. If the value/code cannot be committed with confidence to deliver to the customer, it is a no-go.
3. Employ a test-driven development method to improve quality. Organizations impose a minimum entry criterion, and while that is good for moving forward with the process, attaining that number is not the only goal. When the component/service is hit with instability, recurring issues, and regressions, the numbers get void and raise concerns.
4. Shift everything to the left, and review at every stage. Hold the production whenever necessary. By bringing customer scenarios starting from design and validating the impact at every stage until delivery. Devise a mechanism to perform trade-off analysis at each stage of the Secure Software Development and Operations Life Cycle (SSDOLC).
5. Security & Quality must be implicit, Let the product speak for itself about the design, architecture, and implementation, from day 0.
6. Observe patterns and focus on improving the metrics at critical pathways. For example, retrospect on components/services that are highly degraded, and has recurring issues and escalations. Quickly, understand, introspect, and refactor things for a better future.
7. Avoid short-term hacks, solutions that are not thought through are eventually triggers for excessive burnout, pain, and reactive work. Remember the Volkswagen emissions scandal.

Summary

1. Quality is not a pure metrics play.
2. In the end, if the customer can’t get their job done, and if it is repeatedly painful, it is extremely frustrating to everyone, and the pain is felt everywhere.
3. Security & quality must be team DNA, shift everything we do to the left, and proactively plan.