planning, Good vs. bad code

Ed has made an interesting observation on Tesugen'sPeter's entry Good vs. bad code:

"The above quote just needs the one small edit I've made. Planning is a critical part of all development (i.e. determining objectives, users, requirements, design, etc), and to suggest otherwise is misleading."

And here is Tesugen'sPeter's quote referred by Ed:

"But with some apps, you just know that they are well written. Those apps speak their quality loudly. They are coherent, they have integrity, their UIs make perfect sense, they behave as you expect, and so on. Why is this a good sign of the code being clean? Because software can’t be planned. Software is always a dialogue with its users, with competing software, and with its programmers. Good software adapts, and for adaptations to take place gracefully, the code must be susceptible to changes. Bad code isn’t."

I definitely agree with Ed's observation. Planning is an important and indispensable part of any software or application development. Without proper planning, the software will perhaps be much more far away from its target functionality. Even the phrase 'target functionality' is very fluid as it almost always changes during the cycle of software development. Or, should I better say the planned functionality ought to change if one is to produce quality software.

Perhaps it is this concept of the 'moving target' always in flux that TesugenPeter has in mind when stating that "Good software adapts, and for adaptations to take place gracefully, the code must be susceptible to changes”. So, if by "Because software can’t be planned" it is meant to say that the initial plan is never modified, than it is justifiable to say that software can not be planned. Indeed, such planning that does not modify itself throughout the process of software development from inception, to functional requirements writing, to development, testing and deployment, is no plan at all because it wrongly assumes it knows all there is to know about the final software product. In most instances this is not true. To act otherwise leads to bad software functionality.
You may want to check the following entry that touches on the issues of Adaptive Structuration Theory and its relevance to software development, stressing on the issues of software features and spirit. From Adaptive Structuration and Information Use in distributed organizations:

"That the decision-making and the institutional schools are not appropriate explanation models if considered in isolation can be seen in light of technology's features and spirit. The social structure provided by any advanced information technology (AIT) can be described by its structural features (rules, resources, capabilities, etc.) and by technology's spirit as it emanates from the feature set. The spirit is the intent of the feature set in regards to values and goals, it is actually what the designers think and believe the feature set can do and how should it be used within the institutional/social structures. The spirit is in flux at the early stages of technology's development. It becomes stable as the technology matures, but by this time the technology has impacted the social structures and it has been impacted by them as well: "So, there are structures in technology, on the one hand, and structures in actions, on the other. The two are continually intertwined; there is a recursive relationship between the technology and action, each iteratively shaping the other" (Desanctis, p. 125)."

Having said the above, another statement is a bit puzzling: "But with some apps, you just know that they are well written. Those apps speak their quality loudly. They are coherent, they have integrity, their UIs make perfect sense, they behave as you expect, and so on."

The above quote insinuates some sort of a correlation between bad/clean code and software/apps behavior. From personal experience I know this is not necessarily true. A particular code can be neat and clean, and yet does not behave as expected. Of course, the emphasis here is on 'as expected'. I think that the correlation of expected behavior is stronger and more relevant with the systems (functional) requirements and design documentation.