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.
well, software is 5th way of storing knowledge (see Philip Armour [1]) - i.e. it is "canned"/"frozen" communication, but with automatic (machine) -interpretability - which uncans/unfreezees pieces when using them then freezes again.
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..
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...
[1] https://software-engineering-book.com/