The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence.
I’ve always had misgivings about this quote. In my experience about 90% of the code on a large project is an artifact of a poor requirement analysis/architecture/design/implementation. (Sendmail comes to mind.) I have seen 10,000-line packages melting away when a feature is redesigned with more functionality and improved reliability and maintainability.
The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence.
This is true, but the connotations need to be applied cautiously. Complexity is necessary, but it is still something to be minimised wherever practical. Things should be as simple as possible but not simpler.
This isn’t necessarily true if the complexity is very intuitive. If it takes ten thousand lines of code to accurately describe the action “jump three feet in the air”, then those ten thousand lines of code are describing what a jump is, what to do while in mid-air, what it means to land, and other things that humans may grasp intuitively (assuming that the actor is constructed in a manner similar to a human).
Additionally, there are some complex features which are not specific to the software. We don’t need to describe how a particular program receives feedback from the motor and sensors, how it translates the input of its devices, if these features are common to most similar programs—the description of those processes is part of the default, part of the background that we assume along with everything else we don’t need to derive from fundamental physics.
In other words, the complexity of software may correspond to a feature which humans may be able to understand as simple—because we have the prior knowledge necessary, courtesy of common nature and nurture. A full description of complexity is necessary if and only if it is surprising to our intuition.
That is, in some sense, his point—a phrase like “jump three feet in the air” does abstract most of the computational essence, making it seem like a trivial problem what it really, really isn’t.
The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence.
Fred P. Brooks, No Silver Bullet
I’ve always had misgivings about this quote. In my experience about 90% of the code on a large project is an artifact of a poor requirement analysis/architecture/design/implementation. (Sendmail comes to mind.) I have seen 10,000-line packages melting away when a feature is redesigned with more functionality and improved reliability and maintainability.
This is true, but the connotations need to be applied cautiously. Complexity is necessary, but it is still something to be minimised wherever practical. Things should be as simple as possible but not simpler.
More concretely, sometimes software can be simplified and improved at the same time.
This isn’t necessarily true if the complexity is very intuitive. If it takes ten thousand lines of code to accurately describe the action “jump three feet in the air”, then those ten thousand lines of code are describing what a jump is, what to do while in mid-air, what it means to land, and other things that humans may grasp intuitively (assuming that the actor is constructed in a manner similar to a human).
Additionally, there are some complex features which are not specific to the software. We don’t need to describe how a particular program receives feedback from the motor and sensors, how it translates the input of its devices, if these features are common to most similar programs—the description of those processes is part of the default, part of the background that we assume along with everything else we don’t need to derive from fundamental physics.
In other words, the complexity of software may correspond to a feature which humans may be able to understand as simple—because we have the prior knowledge necessary, courtesy of common nature and nurture. A full description of complexity is necessary if and only if it is surprising to our intuition.
That is, in some sense, his point—a phrase like “jump three feet in the air” does abstract most of the computational essence, making it seem like a trivial problem what it really, really isn’t.