The Laws of Software Process: A New Model for the Production and Management of Software, 2003, Phillip Armour
http://www.amazon.com/Laws-Software-Process-Production-Manag...
about Software as knowledge medium, and effects thereof
some excerpts:
... software is not a product but a medium for storing knowledge, and software development is not a product-producing activity, it is a knowledge-acquiring activity.
... the real job is not writing the code, or even building the system - it is acquiring the necessary knowledge to build the system... Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product.
... When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed.
"... for the most part, (software) engineers do not _know_ how to build the systems they are trying to build; it's their job to _find_ out how to do it." i.e. programmers must be able to learn (and teach) - should learn that and/or be taught to it. All else are tools supporting that activity.
here some part: https://cacm.acm.org/opinion/the-five-orders-of-ignorance/
-- Software is 5th form of ~life-invented knowledge-storing/representing-medium - the previous ones being DNA, brain, hardware, books.
Which IMO, is exactly what it is. Whether its gigabytes of code or algorithm/structure written on napkin.. all the same.
[0] https://cacm.acm.org/opinion/the-five-orders-of-ignorance/
[1] http://www.amazon.com/Laws-Software-Process-Production-Manag...
Quoting works of Phillip Armour [0], circa 2000-2003:
... software is not a product but a medium for storing knowledge, and software development is not a product-producing activity, it is a knowledge-acquiring activity.
... the real job is not writing the code, or even building the system - it is acquiring the necessary knowledge to build the system... Code is simply a by-product of this activity. The problem arises when we think the code, rather than the knowledge in the code, is the product.
... When we use models and mindsets that are rigid and deterministic to manage an activity that is fluid and variable, it is not surprising that people get disappointed.
------
so, IMO, it's the nature of Software (=knowledge) that spoils the (most) practitioneers - there's no gravity (or reality as such) there, so everything is (or seems) possible. And once you learn that "easy" way.. hard to unlearn.
The software as engineering discipline needs a set of substitutes for the missing nature/reality's "laws/rules". i.e. Resiliency might be one.. All the titles of the chapters of the textbooks [1] might be candidates (correctness, maintainability/ repairability, flexibility, portability, understandability, ...). And then, depending on the domain / importance, choose smaller or bigger subset, with looser or tighter conditions.
Easier to say than do it.. Most systematically-thinking people would do it implicitly - but that as well may (or will) contradict the business goals.
Just thinking aloud..
[0] http://www.amazon.com/Laws-Software-Process-Production-Manag...
so i guess, anything related to Communication, applies here. And if the machine interpretation is 1000 times faster/stronger/stricter, then multiply by 1000 too..
[1] https://www.amazon.com/Laws-Software-Process-Production-Mana...
Published as book - The Laws of Software Process: A New Model for the Production and Management of Software , 2003, Phillip G. Armour
https://www.amazon.com/Laws-Software-Process-Production-Mana...