| yeah. far from well-understood. have a look at Phillip Armour's "The Laws of Software Process: A New Model for the Production and Management of Software, 2003"
it talks about Software as knowledge medium, and effects thereof.. an attempt to put them things with their legs down, not up. ... 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. and a consequence: "... 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. |
Absolutely true.
It is also true of all other disciplines of Engineering. The difference with Software Engineering seems to be that there are no Physical/Natural laws/constants to inform the Programmer of explicit boundaries/limitations and hence a stopping point.