The drive method doesn't change anything.

Have you ever heard of a professional software developer who should master a driver approach? These drive methods may be: domain-driven design (domain-driven), test-driven development (Test-driven Development), Behavior-driven development (Behavior-driven Development), Data-driven design (data-driven), data-driven development (Data-driven Development), use-case-driven design, use-case-driven development (with Case-driven Development), architecture-driven design (architecture-driven), architecture-driven Development (Architecture-driven Development), model-driven development (Model-driven Development), agile model-driven development (Agile Model-driven Development), and so on. I have indeed heard of such a request.

We expect these drive methods (or what I call the psychological framework, the mental framework) to have some kind of magic, because we like frames. We often forget that for our skills, they only play a supporting role, not a software professional's sole goal. But this love of the framework has led us to some cognitive biases that allow us to make an in-depth analysis.

How is the psychological framework produced?

These so-called driving methods are examples of what is called a psychological framework tool. A mental framework, like a software framework, is a construct (some idea or process) that can be used for development activities, such as modeling, designing, programming, or testing in an orderly fashion. We will analyze three psychological frameworks: domain-driven design, test-driven development, and behavior-driven development. They are a very popular driving method in the community.

The founders of these frameworks assume that they will be able to promote development efforts through the following approaches:

Make common ideas (such as object modeling and testing) more specific;

Introducing an orderly working method;

Show complex activities in a repeatable step form.

It all boils down to a commitment and an appealing cultural gene.

When the author presents a mental framework, it means a promise that everything will be better, more efficient, faster, cheaper, and everything will be fine from now on. Typically, a commitment is related to the problems that a developer encounters in the process of applying a particular concept, and it is arbitrarily assumed that these issues will be resolved when the proposed framework is used. Test-driven development is a good example. Its commitments include: "You will no longer need the debugger", "you will have simple and high-quality code", "Your code in the product phase of fewer bugs." I'm not saying these are short promises. I mean these commitments do not have clear, verifiable data support in the early years of TDD. There is a passion for TDD, and then there are some metrics to validate its commitment.

What makes these mental framework commitments so "appealing"? There is no doubt that one of the factors is that we want to solve all problems. So when the problem is bigger, the more likely we are to adopt it. Another factor is the contagious cultural gene (contagious meme). Just as the gene is the unit of genetic information, the byte is the unit of the digital message, the cultural gene is the basic unit of culture. The word was created by the British evolutionary biologist and author Richard Dawkins, who sees it as a replicator (replicator).

Each framework defines its own cultural genes, appealing slogans that allow developers to relate it to specific frameworks and their commitments. Typically, this cultural gene describes a major concept promoted by the framework. The TDD culture gene is a good example of red-green-refactoring (Red-green-refactor), which is no different from the plan-execute-check-process loop (plan-do-check-act cycle, abbreviated to the PCDA or called Deming Loops). PDCA Cycle is an iterative and adaptive process for continuous improvement of products and services. Red-green-refactoring, this short slogan has the following characteristics:

It expresses the basic technology of TDD in three words;

It's easy to remember;

It describes visual tools to support TDD.

These three words allow you to describe TDD in simple words. You do not need to propose well-designed concepts, detailed definitions and distinguishing specific cases or complex steps. It's simple, it's red-green-refactoring.

In table 1, I set out examples of psychological frameworks, their commitments and their attractive cultural genes.

Table 1

Framework	Its commitment to	Cultural genes that attract people
Tdd	Your product will have virtually no visible bugs and will not produce too much code except for the necessary code.	Red-green-refactoring, unit test?
Bdd	You associate TDD with functional requirements	Given, when, Then
Ddd	The application architecture fully reflects the real business, so the implementation of subsequent requirements will be very natural; there are no workarounds, no secret paths, only pure, unaffected, and independent models.