I agree almost totally. But I would frame this differently:

> Types, tests, frameworks, dry, language features, ci pipelines, scrum whatnot. All just fun party tricks that fall short when your building the wrong thing.

Some or all of these might be excellent tools in service of solving your problem in its domain. They may be even essential for solving it. And they might be the wrong tools. It’s situational, and evaluating the appropriateness of each, how and why they fit, is part of modeling the problem domain just as much as designing the appropriate data structures, or state machine flow, or any other mechanism for expressing the domain.

Agreed, properly modeling domain knowledge without types for example feels insurmountable to me. Maybe there exist a category of programmer who can do this, but why make programming more difficult than it already is.

How do you realize that one is building the wrong thing?

Not OP, but asking yourself who would use what your building, and then checking whether they will use what you build is a good start. Of course, the "checking" part is hard, even with a lot of methodology.