This was the title of my book published back in 2003 [1]. Its target audience was, of course, software folks, but I think many of the concepts are universal and, at least somewhat, cover any human knowledge acqusition activity. As with all of the ideas in this website, you are free to choose which you find useful.
The initial three "laws"[2] are:
The First Law: You can only have a process for something you know how to do.
There are a few twists to this that I will discuss later (like what do I mean by "process"). But basically, this is quite self-evident. At the simplest level a "process" consists of actions, usually in some sequence, and also usually with some predicate logic that operates on some data or material and may also control the action sequence. Also implied are things on which the process operates and the output the process produces.
All of these are knowledge elements. The process is simply the storage of those process knowledge elements in some medium [3].
The Second Law: We can only define software process at two levels: (1) Too vague or (2) Too confining
This, in its definition above, is specific to software development. But this law applies to any knowledge acquisition / discovery / creation situation whether is is software or not.
Any predefined process aiming to guide knowledge acquisition will tend to define the steps and actions as either overly non-specific or as overly constraining [4].
We will cover this in more detail later.
The Third Law: The very last type of knowledge to be transcribed into an executable software medium will be the knowledge of how to transcribe knowledge into the executable software medium.
This is also known as: "The Footware Manufacturer's Minor Dependent Law"
This "law" is also quite specific to software. Until recently, almost all software was written by people and much of the process these people used was stored in their heads (knowledge-in-brains) and in paper process or the equivalent electronically stored documentation (knowledge-in-books).
The richest source of software-stored knowledge available for reuse has been in the creation of software languages where discrete functionality has been packaged into the language primitives. This has largely replaced the need to learn how to execute this functionality with the need to learn the programming language syntax and use. Large-scale system-level functionality is still mostly crafted by humans[5]
We will explore the ramifications of these "laws" in the large sense of knowledge creation, transcription, communication, and storage over the next few pages.
FOOTNOTES
[1] Phillip G. Armour The Laws of Software Process: A New Model for the Production and Management of Software Auerbach 2003 ISBN-10 : 0849314895
ISBN-13 : 978-0849314896.
[2] These are not "laws" in an explicit and definitive sense, more like heuristics such as "Murphy's Law". So, some of the observations are intentionally wry and are not to be taken too seriously.
[3] That "process" defined here is limited to the storage, rather than the acquisition of knowledge since the First Law statement specifies "...know how to do..." which means the knowledge has already been acquired. Of course, there can be a "process" for acquiring knowledge but this is dependent on the storage target and, if the knowledge is entirely "new" and is being acquired the first time for anyone, the mechanism used must be more akin to a "meta-process" than a prescriptive stepwise process.
[4] This is saying much the same thing as footnote [3] above. True knowledge discovery must not be overly confining.
[5] The advent of AI-driven systems development is chipping away at this. But while such approaches can, at present, create quite complex computer systems, they still have to be initiated by the input of some requirements by a human. That is, a person still has to instruct the AI system what needs to be done while leaving the system to decide how it will be donw. This is likely to change in the very near future and AI may create systems without any input from humans at all.