The artefacts that we regularly produce in collaboration with various subject matter experts contain deep domain-specific knowledge (in insurance product design, automated building control, financial product design, ...). The required knowledge comes in three parts:
- SCIENCE: The first part of knowledge has been obtained using the scientific method.
- DOMAIN: The second part constitutes the accumulated wisdom from many years of working (developing heuristics) in the particular domain.
- MOMO: The third part relates to expertise in modelling, abstraction, and modularisation (a catalyst in the process of formalising knowledge).
This gets to the heart of the debate about the degree to which software development involves science!
Mature Application Development
If optimal - domain/organisation-specific - methods & tools are available to produce the artefacts that constitute the outcome of the project, then no knowledge of type SCIENCE is required, as all such knowledge is encapsulated in the software production method & tools.
If a project includes the development of domain/organisation-specific tools needed to develop the desired solution, then significant knowledge of type MOMO is required, and some knowledge of type SCIENCE may be required. Such projects are typically risky, and must be broken into separate domain engineering and application development streams to contain and incrementally eliminate the risks.
Such projects are only economically viable if the subject matter experts involved have been active participants in at least two prior software development efforts in the particular domain. Otherwise the available knowledge of type DOMAIN is insufficient for the development of domain/organisation-specific methods & tools.
Experimental Application Development
If knowledge of type DOMAIN is lacking, then the software development project is by definition based on trial-and error, and the approach must be highly agile in order to minimise waste. Luke Hohmann speaks about the need to burn the first one or two pancakes. Using science to improve such projects is impossible until the pancakes have been burnt.
If sufficient knowledge of type DOMAIN is available, then it can be combined with knowledge of type MOMO to develop optimal domain/ organisation-specific methods & tools.
The application of knowledge of type MOMO can be expressed mathematically, making use of set theory, group theory, model theory, and concepts from the theory of denotational semantics. These mathematical theories provide a solid foundation for domain engineering - which can be described as combining knowledge of type DOMAIN with knowledge of type MOMO.
Once domain engineering has been performed, application development only requires knowledge of type DOMAIN, and further domain "engineering" is only needed if the project runs into limitations of the domain/organisation-specific method & tools.