Structure and emergent design.
Whatever the illusive, "Emergent design," is, most programmers would agree that source code structure certainly plays a part. Indeed, wikipedia asserts that emergent design concerns nothing but refactoring, which is nothing but changing source code structure:
"Development will take a piece of functionality A and implement it ... then move on to delivering functionality B. Once B is built, or while it is being built, the organization will look at what A and B have in common and refactor out the commonality, allowing the design to emerge."
"Emergent design," tends to involve something brought into being without planning or significant advance preparation. The concept relates closely to - and may even be a consequence of - the YAGNI principle.
The opposite of, "Emergent design," in the above case would have been to analyze both features and design commonalities before any implementation had begun.
Emergent design offers a great benefit over design-up-front because design-up-front makes assumptions about future development and those assumptions may be wrong. Wrong assumptions waste money by triggering the design of code that is never built and for which customers never pay.
Emergent design entails fewer such future-development assumptions because it is a response to actual on-going work.
Within the commercial software theater, however, certain powerful brutish forces operate from which no good design - no matter how emergent - escapes.
If we look at the syntactic structure of a system, the overriding commercial force pressing on it is that which demands that it be cheap to change. To do this, the structure must avoid expensive ripple effects and so must curtail the number and size of transitive dependencies that bind all its parts together.
Bad software structure pays no heed to this force. A beautiful orchid, it sends its root tangling deep into rich artistic loam, its developers breathless before the sheer unpredictability. The individual packages of poorly structured programs can look wildly different from one another depending on the whims of these developer geniuses.
Good software structure, on the other hand, is crushed flat by that commercial force on all levels: method, class and package. Its plants struggle in the unnutritious soil of harsh wind-swept granite crevices. The individual packages of well-structured systems all look vaguely - boringly - similar, artistic license revoked, shredded and ridiculed.
The following six spoiklin diagrams show all the classes within individual packages of two Java programs. The program on the left was designed, from the beginning, to be cheap to change. The program on the right is the recently reviewed Apache Lucene, whose design emerged (at least, it's hoped that it emerged: it certainly couldn't have been designed to look the way it does, could it?).
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Of course, even in well-structured systems, the particulars are not predictable and exceptions occur: programmers do not plan in advance whether method a() depends on four other methods or five. Good system structure, however, admits perfectly predictable statistical properties when viewed as an ensemble of parts, the scarcity of deep transitive dependencies prime among them.
Yet if this is the case, can good system structure really be said ever to emerge? Can a system emerge into the precise statistical properties that we want it to express? If we know the statistical properties we wish a system to eventually have and implement purposefully with those in mind, have we not designed up-front?
Summary
To paraphrase Tyler , "Listen up, maggots. Your code structure is not special. It is not a beautiful or unique snowflake. It's the same decaying digital matter as everything else."
Just because your design was unplanned does not mean than it's better than a design whose overall statistical properties could be predicted before fingertip ever touched keyboard.