Today’s prevailing software development methodologies share a worldview of software-as-machine. When we build a machine, such as automobile, we do not consider, or completely ignore, the context (the purpose of using the vehicle) because the use case model, interaction between users and automobiles, is standardized. Software development methodology with machine view is user requirement driven and excludes the context, the problem domain where business value creation and business processes are explained. User interaction with the system does not tell whether it is useful to the business and why questions. The understanding of the business is implicit, incomplete, or largely missed which leads to intellectual rework and business and software misalignment. A low success rate and high intellectual rework in today's software industry are due to the software-as-machine view and epistemic fallacy that explain why software development is guesswork rather than a disciplined inquiry.

Software-as-machine view
The desire to apply a systematic approach of industry engineering design to software implies that software is viewed as a machine. We first specify what the machine, the code, should do (described as features) and then implement these features. Software code is all that is important; everything else is secondary and can be done without. This leads to the view that software development is the same as engineering design. However, the lack of natural constraints and physical dimension in software indicates that generic design that makes tangible materials meet our expectations does not apply to software. Accordingly, this view is most likely a root cause of software engineering theory and practice decoupling.

Epistemic fallacy
The muddling of issues of ontology (the study of being-essentially studying questions of what kinds of entities exist) and issues of epistemology (the study of knowing-essentially studying what knowledge is and how it is possible) is one of the key pitfalls when building a theoretical foundation in any discipline. This muddling is called epistemic fallacy: holding that questions of ontology are reducible to questions of epistemology. The epistemic fallacy would assume that for any question of whether such and such exists, we should substitute the question of how we know that such and such exists.

However, for any theory that we have about what knowledge is, we must have a presupposition about what the world is like. That is, we must assume that the world exists in such a way that it makes our theory of knowledge possible. There is no escaping having a theory of ontology. It is only a question of whether it is consciously acknowledged and studied or left as an implicit presupposition of one's theory of epistemology.

Iterative development is an epistemic fallacy. Starting to build a car without knowing what it is, we may end up with a boat. The narrow definition of time boundaries, the "hurry to show results" syndrome, is one of the greatest sources of cost-regret in today's software design.

Our worldview and philosophy
We view software not as a machine but as a living tree. The first step toward growing a tree is to create a seed, the business model. By having a seed, we have a good idea what of we will get in the end. If we have a acorn we know we will have an oak, not a pine or anything else. The actual shape of the tree is emergent depending on the environment. If we cannot reach the agreement about what the seed should be, the project should be aborted.

Growing the seed within a suitable environment makes a tree. Our software process starts with creating an acceptable seed, providing a good environment, and then allowing the seed to grow within that environment into a shoot (technology model), a sapling (design model), and finally a full-size tree (code model). The environment consists of domain, technical, and software knowledge. We know with confidence how long it takes to create a seed and how long it takes to grow the seed into a tree. Growing a tree is an irreversible, not iterative, process. It is not planned design, because software features are not known until the last step. It is organized emergence-a business-driven and model-oriented approach.