4 Legs Software

Appearance

4 Legs Software

Software Development & The Taguchi Method ​

One of the masters in the world of continual quality improvement was Dr. Genichi Taguchi.

In the Taguchi Method of Quality Control: Definition, Example, and Uses

  • "The Taguchi method gauges quality as a calculation of loss to society associated with a product. In particular, loss in a product is defined by variations and deviations in its function as well as detrimental side effects that result from the product."
  • "Loss from variation in function is a comparison of how much each unit of the product differs in the way it operates. The greater that variance, the more significant the loss in function and quality. This could be represented as a monetary figure denoting how usage has been impacted by defects in the product."

Further, the Taguchi Loss Function is defined by a "parabolic loss function" as a means of calculating the economic loss even by work items that are within specification or meet requirements.

Question 1 & Question 2 ​

Dr. Bill Bellows, who had worked with Dr. Taguchi, explains this concept through what he refers to as question 1 and question 2.

  1. "Does something meet requirements?" .. black or white
  2. "How many ways are there for this thing to meet requirements?" .. shades of gray

There's a story that goes something like this... When some American car manufacturers were visiting a Japanese factory, at the door assembly, they asked:

"Where are the mallets?"

"Mallets?"

"For assembling the doors"

"We don't need mallets" ... was the response.

American manufacturers had been producing parts "to specification", question 1. Some may have been perfectly between the limits of the specifications, others were likely barely within spec. Some fit, some close enough, but they "met requirements".

In Japan, leading from the work of Dr. Taguchi, they were thinking past question 1. Question 2, or "shades of gray thinking", by studying the variation, they would continually iterate towards tighter control limits (less & less variation). As a consequence, the doors just assembled easily, "snap fit".

Integration ​

But there's more to it than just less & less variation or simply precision. It is about the importance of integration. It is not enough to be precise within specifications (question 1). Dr Taguchi was pointing out the importance of finding the best "target value" and producing outcomes that are more accurate to that target. This is what will impart the least amount of loss to the customer.

"Reducing Variability: A New Approach to Quality"

  • "Reducing Variability: A New Approach to Quality" by L. P. Sullivan, Quality Progress, July 1984.
    (Note: the annotations in red are my own.)

But there’s a catch, this target will change over time. We need to continually checkin and communicate with our customer (internal or external to our company).

Software Development ​

When it comes to software development, what contributes to this “target value”?

  • Code
  • Deployment
  • Unit tests
  • Acceptance tests
  • Integration

How can we then answer the question:

Does this feature, or this one part of this feature, “snap fit” into the product that works optimally for the user?

Test Driven Development (TDD) ​

Is your mindset Question 1 or are you looking to answer Question 2?

As an example of Question 1 and a focus on "meets requirements", you could write some code that you think gets everything in place for your feature. Perhaps you've mostly ignored unit tests so far, so you push to a branch and let the CI service run all the existing tests for you. A few tests break, so you fix those and push again. They all pass now. Meets requirements.

A test-driven approach however is more of a Question 2 type of process with "shades of gray" thinking. We write a failing test as an initial target condition. We get that to pass. Our feature is not complete, but we merge and deploy, because our focus is on integration. If anything isn't quite right, we will adapt and adjust our target. Otherwise, we define our next target condition and repeat until our customer is satisfied with the outcome. This can additionally be codified in an outer integration test loop, an acceptance test. Always focusing on "snap fit" integration with the overall system.

Wrap Up ​

There is a lot to unpack from Dr Taguchi's work and trying to leverage it within software delivery. Honestly, there's a lot unpack around all the benefits from test-driven development. This is just a micro-view of each. My point is to think beyond "just make it work". Aim to continually improve the product and the process. Strive for the best means of integration for customer satisfaction and lower cost. Build with the intent to incur the minimal amount of loss from the overall system.

Additional Resources ​

  • v1.0.0 - Feb 14, 2024
  • v0.2.0 - Feb 12, 2024 - Updated from further conversations
  • v0.1.0 - Feb 6, 2024