Despite differences in their tools and skill-sets, designers and developers work on similar problems. Designing classes, interfaces and other software components is a similar exercise to UI design because each component needs to be intuitive to use while being fully featured and configurable. Code, like a UI, needs to be written with the consumer in mind. Decisions about naming and architecture and what to log and what to test, what tools to write and how to handle configuration, etc. are questions of user experience. In other words, programming is not unlike like having to design and name hundreds and thousands of text driven UIs and great names are not always obvious. For example, Chris and I took a full few minutes to decide on a name for the Tuning Chamber's abstraction-layer-interface which mediates input from hallway sensors and lighting output (we decided on “IMotionManager”). Components are nested and bifurcate in a seemingly infinite tree of encapsulation and dependencies.

The “scale-invariant” nature of software is the reason we can talk about software architecture or a programming language as either “high” or “low” level. Writing software is about grappling with and taming the complexity that emerges from various layers of abstraction and embedded functionality. The evolution of a software project is not unlike the coastline paradox in the way new levels of complexity emerge as a perspective changes. This emergent complexity contributes to the problem of projecting how long it will take to complete a software project or feature.

The coast of Britain seen at very different scales on Google Maps:

The H-Tree Fractal is used in the VSLI process for laying out transistors on integrated circuits as an area efficient embedding of binary trees (Wolfram Demonstrations Project):

‍

‍

The fractal nature of software architecture explored through Visual Studio's built-in dependency-graph tool - a small section of the Tuning Chamber Project:

‍