Numbers in Decision-making

Chang said she’s not surprised by the influence numbers have on behavioral decision-making, but what stands out to her is the robustness of the effect, which was replicated across 21 experiments involving 23,000 randomly selected participants. Despite the significant sample size, the predilection for numbers never wavered, except when numbers were presented in ways that were harder to process. Chang and her co-authors describe the mechanism underlying quantification fixation as “comparison fluency,” or the ease of judging numerical values compared with non-numbers, such as words and pictures.

How Numbers Drive Behavioral Decision-making

Katherine Milkman, one of the coauthors, is a scholar I follow pretty closely, and this article seems pretty insightful and I’ll be reading the research this week. Our field has some difficulty here, none no more so in the mixed legacy of Deming on the subject, mostly misinterpretations if you ask me. Mark Graban wrote a great post on that last year.

Stop it with the 4.0 stuff

Industry 4.0, Quality 4.0, Validaiton 4.0. It is all absurd, so cut it out. Old man rant out.

Seriously though, let’s have a chat about this and why it is a bad practice.

When we put a number after something, we denote a version number. Version numbers have meaning, and individuals react to them in a certain way.

Understanding Version Numbers

A version number is a unique identifier assigned to specific releases of software, hardware, firmware, or drivers. It helps developers and users track changes, improvements, and updates in the product over time. Version numbers are crucial for maintaining software, ensuring compatibility, and managing updates effectively.

Structure of Version Numbers

Version numbers typically follow a structured format, often in the form of major.minor.patch or major.minor.patch.build. Each segment of the version number conveys specific information about the changes made in that release.

Major Version

  • Indicates: Significant changes or overhauls.
  • Example: Going from version 1.0.0 to 2.0.0 might indicate a complete redesign or the addition of major new features.
  • Impact: These changes might not be backward compatible with previous versions.

Minor Version

  • Indicates: Addition of new features or significant improvements that are backward compatible.
  • Example: Updating from version 2.1.0 to 2.2.0 could mean new functionalities were added without altering existing ones.
  • Impact: Users can expect enhancements without losing compatibility with previous minor versions.

Patch Version

  • Indicates: Bug fixes and minor improvements.
  • Example: Moving from version 2.2.1 to 2.2.2 might mean minor bugs were fixed.
  • Impact: These updates are usually safe and recommended as they resolve issues without changing functionality.

Build Number

  • Indicates: Specific builds or iterations, often used internally.
  • Example: Version 2.2.2.45 could indicate the 45th build of this particular version.
  • Impact: Helps in identifying specific builds, useful for debugging and internal tracking.

Semantic Versioning

One of the most widely adopted systems for versioning is Semantic Versioning (SemVer). It uses a three-part version number: major.minor.patch. This system provides a clear and standardized way to communicate the nature of changes in each release.

  • Major: Incompatible API changes.
  • Minor: Backward-compatible functionality added.
  • Patch: Backward-compatible bug fixes.

Importance of Version Numbers

  1. Tracking Changes: Helps developers and users keep track of what changes have been made and when.
  2. Compatibility: Ensures that users know whether new versions will work with their current setup.
  3. Support and Maintenance: Facilitates efficient troubleshooting and support by identifying the exact version in use.
  4. Update Management: Allows users to determine if they need to update their software to the latest version.

Why I Dislike Quality 4.0, Validation 4.0, and the Like

It is meant to denote a major version, but it’s not, for a lot of reasons:

  1. These concepts are more growth of design boxes than major changes. To use version control lingo, there is a lot of backward compatibility.
  2. They are not definitive. There are absolutes and best practices and onward progression.
  3. Each company tends to be in different places in different ways, and there are many maturity scales, not just one.

Maturity models are a better option. Each of these buckets has multiple scales, each of which needs to be evaluated and improved.

This is why I like cGMP

The “c” in cGMP stands for “current,” which signifies that the Good Manufacturing Practices (GMP) being referred to are up-to-date with the latest standards and technologies. This differentiation emphasizes that companies must use the most recent and advanced technologies and systems to comply with the regulations set forth by the FDA. The term cGMP ensures that manufacturing practices are not only good but also current, reflecting ongoing improvements and updates in the industry.