software-architecture riomhaire microservices deming

Deming's Perspective on Fad-Following in Software Architecture

Posted by Riomhaire Research on Saturday, August 16, 2025

Deming’s Perspective on Fad-Following in Software Architecture

William Edwards Deming, known as the “father of the quality movement,” was influential in rebuilding Japan after WWII. He revolutionised Japanese industry with his management theories, criticising trend-following as poor, fear-driven, short-term management lacking a scientific basis.

Over my career, I have seen many companies and development teams being “fad-driven” at many different levels:

  • Deployment: For many products, Initially In-house deployed, then AWS deployed, then Mesos, and finally Kubernetes.
  • Technology: A product which started off using RESTful APIs, then moved to JMS, followed by RabbitMQ, and finally Kafka.
  • Architecture: Started with a Monolith, then split into microservices, then rewritten as cleaner microservices, then gradually moved back to a monolith-microservice mix.

From a customer’s perspective, none of these has much to do with the actual product the customer uses.

Lately, I have been reading a lot about W. Edwards Deming, Kaizen, and related matters, and I have wondered what Deming would have thought about our fad-driven IT industry. These are my thoughts based primarily on Deming’s “14 principles of management”.

Core Deming Objections

“Drive Out Fear” (Point 8)

  • Fad adoption within software engineering often stems from fear of being left behind, or finding a fix (usually quick) for a severe problem, rather than performing a rational analysis.
  • Frequent adoption or change of technology creates anxiety-driven decision-making instead of data-driven choices. Teams will begin to distrust decisions taken by management and architecture.
  • Skills and experience are expensive to acquire in both time and money. Managers and architects fear appearing “outdated”, so they jump on trends without really understanding deeply the technology or if it is justified.

“Cease Dependence on Inspection” (Point 3)

  • Fads promise quick fixes or rework of existing systems rather than building quality into the process. They are not necessarily bad, but in the short term, disruptive from a systems and quality perspective.
  • Architecture decisions should be based on continuous piecemeal kaizen improvement, not periodic wholesale changes.
  • Focus should be on preventing problems, not adopting the latest “solution” or “silver bullet”.

“Institute Training and Education” (Points 6 & 13)

  • Fad-chasing often means abandoning institutional knowledge.
  • Teams constantly retrain on new technologies instead of mastering fundamentals, which is expensive in terms of time and money. Teams will lose members who resist change, as well as those who have acquired the necessary knowledge and then seek better opportunities elsewhere.
  • Undertaking new approaches without understanding when/why they’re appropriate and what the limitations, short and long, are. The “happy path” is a close friend of the “new fad”.

Deming’s Alternative Approach

Statistical Thinking

  • Measure current system performance before changing the architecture.
  • Use control charts to understand system variation and capability. Often, “bottlenecks” and other capabilities can be improved by the application of knowledge and Kaizen.
  • Make changes based on data, not industry buzz.

Long-term Optimisation

  • Focus on customer value delivery rather than technological novelty. The customer is interested in what the product does and not how it is produced or built.
  • Build organisational learning around proven principles.
  • “Constancy of purpose” - consistent architectural philosophy vs. constant reinvention. Although “lean” encourages change, it does not advocate for “throwing the baby out with the bath water” merely for the sake of it.

Systems Thinking

  • Understand the interdependencies and pressure points before making architectural changes.
  • Consider the total cost of ownership, not just implementation excitement
  • Recognise that architectural decisions cascade through the entire organisation, and that changes can take time to see any effects - good or bad, and especially any side-effects.

What Deming Would Recommend

  1. Establish architectural principles based on business needs, not trends
  2. Measure and understand current system performance
  3. Pilot new approaches with proper statistical controls
  4. Build organisational capability rather than chasing silver bullets
  5. Focus on customer outcomes rather than technical fashion

As Deming is quoted as saying:

  • “It is not necessary to change. Survival is not mandatory.”
  • “Change based on knowledge and customer needs, not because everyone else is doing it.”

Good advice for any systems architect or business leader.

Supporting Material

CATALOG