What is a fractal?
From Wikipedia:
“Fractals are typically self-similar patterns, where self-similar means they are “the same from near as from far”.”
What aspects of web development and associated project management might have an underlying fractal geometry if viewed through a particular lens?
Can aspects of web development be more specifically described with a particular fractal dimension? What kinds and how much data would suffice to assign a fractal dimension to such aspects?
We can easily see that hierarchies are rampant throughout software development (see parent child relationships, nested hierarchies, XML document object models, nested folder structures, etc), at an organizational level (see org charts), information architectures (site maps are essentially pure hierarchies almost by definition, and web designers routinely interpret site needs in terms of information hierarchies. Is hierarchical topology in itself fractal, and if so, what are the fractal dimensions at play? For such hierarchies, a branching fractal geometry springs to mind, but is this a formal description, or superficial? What underlying processes, maths, or dynamics are work for such contexts that are meaningfully described by fractals, i.e. would a fractal description provide any additional insight into these elements of web and software, and the meta-structures involved in web structure development?
Beyond the hierarchical structures, are there other fractal geometries at play?
Perhaps even in a manner not neatly described with conventional fractal geometries that are easily visualized or modeled, perhaps there are structures, or process elements that mimic themselves in a generally fractal like way at various scales. Non-hierarchical architectures, modular architectures, the omnipresent “scalable” architectures, in which the microstructures of code are structural proxies for their parents, and so on up to the server level, the API level, and larger “cloud” architectures.
What can we learn from these relationships, and should there be a discernable math that might well describe these forms, visualizable or not, who cares?
Well, it may well matter, whether we are conscious of this lens or not. It’s possible, that should we cherry-pick a particularly compelling component of the web development or associated processes, and apply some fractal analysis with sufficient rigour, the study will shed light on the way we work. The analysis may even provide a metric for some sort of efficiency, i.e. perhaps there is a fractal geometry or dimension that we should strive for. That is, if the analysis proves fruitful in the sense that a methodology for measuring fractal dimension of a given process emerges, this could be used as a persistent tool to gauge effectiveness, or perhaps completeness, yielding a better, more elegant product.
An interesting candidate for this approach might be to evaluate the fractal dimension of technical documentation. We might speculate that early in the discovery process, the dimension is low, mainly because detail is low because discussion is “high level”, organizational level is weak given that scope is essentially highly volatile, evolving and dynamic. For a software or web development project, code and associated technical and engineering documentation is either provisional, e.g. a tentative “out-of-box” framework is all that is known. Thus the technical or engineering documentation (code commenting, scaffolding documentation) is all comparably minimal, weak, low resolution.
As discovery proceeds, information is gleaned, scope is refined and firmed up, requirements are gradually locked, accompanying assets (e.g. wire-frames, design comps) are developed and documented themselves. Critically, nesting and hierarchical relationships are refined, and critically (also), their depth is increased. Interestingly, documents and assets are cross-referenced, increasing what are essentially informational network relationships (is this a thing?). This last element suggests that we’re not only tracking hierarchy depth, but the texture of the documentation.
As sign-offs and approvals occur, documents and assets are formatted, formalized, napkin sketches are converted into share-able digital assets or collaborative documents. Code scaffolding and prototypes provide proof of concept for various predictive, preliminary or tentative requirements concepts. Designs are finalized at fine grain, high resolution. Documentation is brought into consistency across sources, both in tone, technical language, but also in terms of the style of the documentation itself, system nomenclature, system definitions, table of contents’, internal document referencing and cross-document referencing. As the production stage approaches, the project requirements and documentation have crystallized. Where flexibility and unknowns persist, even these elements are framed, so that the system balance and project scope is maintained.
Through these stages of documentation, and requirements formalization, we may be able to track or tag or watch fractal dimension change. Perhaps with a more user friendly term, but regardless, this value, a quantifiable thing, could be used to evaluate the progress of a project in a more meaningful way than the common “gut level” metric, typically characterized by the Gantt chart “% complete”. Percentage complete is typically based on a crude ratio of open to closed tickets within a given milestone, or perhaps more commonly, a producer’s “guestimate”.
What are some ways we could go about this?
Most fractal analysis is done in describing naturalistic phenomena and morphologies — things like coastlines, river systems, branching patterns in plants, fracture patterns in rocks, and so on. Given that software or product documentation is an entirely artificial form, perhaps this right away rules out the approach? I suspect that the reality of projects is that because they are human affairs, they may exhibit behaviors, processes, and therefore present structures characterized by complexity, and thus may also exhibit fractal geometry. Experience suggest that there may be an organic or complex quality to project management, and more going back to our example — documentation evolution. Going on this premise as an assumption, the next question is, how might we explicitly measure documentation refinement in the geometric terms that are typically used to measure fractal dimensionality? A few ideas here ..
Brute for image processing techniques. Some level of control is implied, e.g. all documentation is done in a given program (e.g. Google Documents), all design evolves (e.g. within Photoshop), or wire-frames (e.g. within Axure). For given production “containers” as these, an image analysis program or algorithm could be developed to measure and assess the granularity, structural detail, smoothness, of the given asset over time. A basic model algorithm might be considered that measures (crudely), indentations, bullets and associated nesting depth, formatting rules applied.
It’s just a hunch, but if it works, the algorithm, i.e. a program could be running in the background that would provide a more elemental gauge of project completeness, at least as we at Knectar as a shop have come to require it in developing great end-products.
If you are a fractal specialist and interested in collaborating on this project, contact me at chris dot amato at knectar dot com.
