Over a million developers have joined DZone.

Your Code Structure Isn't Special: Hazards of Emergent Design

Yes, you can't design everything up-front. Sure, code emerges, like life. But life culls as much as it creates. See how bad these badly-designed dependencies look.

· Integration Zone

Visually compose APIs with easy-to-use tooling. Learn how IBM API Connect provides near-universal access to data and services both on-premises and in the cloud, brought to you in partnership with IBM.

Whatever the elusive "emergent design" really 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?).

Image generated by Spoiklin Soice

Figure 1.

Image generated by Spoiklin Soice

Figure 2.

Image generated by Spoiklin Soice

Figure 3.

Image generated by Spoiklin Soice

Figure 4.

Image generated by Spoiklin Soice

Figure 5.

Image generated by Spoiklin Soice

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?


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.

Visually compose APIs with easy-to-use tooling. Learn how IBM API Connect provides near-universal access to data and services both on-premises and in the cloud, brought to you in partnership with IBM.

design,emergent,code structure,clean code

Published at DZone with permission of Edmund Kirwan, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}