Architects vs. Gardeners

Recently I watched a talk given by Chris Butcher at GDC2015 called Learning From the Core Engine Architecture of Destiny (Slides). In it he makes the same comparison of architects and gardeners and makes the argument that in the realm of systems as complex as modern game engines engineers should think of themselves as software gardeners.

We work in environments that are messy, full of sprawling life and complexity. We spend our days grappling with the limits of our ability to effect change. We don’t really get to build new things any more. But… there is a joy to be found in the work still.

When I saw that comparison I immediately thought of Frank Chimero’s article about the same topic which kicked off an impromptu Design Systems Blogathon last year. I’m not sure you can easily compare the complexity (especially on a technical level) of game engines vs. design systems but they fit into the same category of tying many different areas together into one cohesive unit to produce finished products, and by extension inevitably face that same decision of restarting from scratch or continuing to maintain and iterate over time.

A few other big points stick out to me from Chris’ talk:

Core vs. Feature

The Tiger Engine behind Destiny can be loosely divided into two groups: core components and feature components. Core components are usually designed together and built around some shared assumptions, the unwritten “rules”, while features use concepts provided by the core and tend to be more loosely-coupled. Core engine components are hard to change; when evaluating how to build Destiny, Bungie’s previous engine made some assumptions like single-threading and a single target platform that caused them to take on a large project to evolve their engine to support their future games.

These core and feature components fit nicely into the pace layers concept, which organizes parts of a whole by rate of change, placing the slowest at the bottom. This concept has also been applied to design systems, although I think design systems take even one more step back and try to codify the shared assumptions as well as organize everything built on top of them.

We can view a design system in a similar way. At its core, a set of guiding principles provide the foundations upon which everything else follows. If conceived with care, while open to periodic amendment, these should remain largely unchanged.

Designing Systems, Part 2: Layers of Longevity by Paul Robert Lloyd

Scaling Out vs. Scaling Up

One of the pain points that was identified during development of Destiny is the fact that as the release gets closer content processing ramps up significantly, and that it’s best to design your content pipeline so that it can scale linearly to better account for that.

For design systems this would relate to how fast new products/sites are being developed and brought to market. Different groups of people usually touch projects connected to design systems: development teams, content writers/editors, QA, etc.

Additional Thoughts

• Adding engineers increases complexity: This is true of pretty much any project; I think the key with a design system though is that it is built to be shared and used by many people, so it is a balancing act of keeping complexity under control and integrating feedback from everyone using it.
• Shims: can cause way more work than they save; I like Chris’ suggestion that a prototype that is intentionally temporary may be a better solution at the end of the day if some components are waiting on dependencies.
• Complexity feedback loops: as a project grows it can take longer to add new features, which can encourage a positive feedback loop of increased complexity as things being to be rushed. It’s important to establish strong architecture to control complexity, which applies just as much to the pieces of a design system. Chris uses one example of utilities like logging and performance tools; the design system equivalent might be an up-to-date component changelog, live examples, and a component inspector.
• Good rule enforcement: this is more of a code-focused one than the rest, but I love the checklist of items to make a successful enforcement system: automatically catching violations, showing how to fix them, and providing a work-around for one-off special cases.
• Evolving existing technology vs. completely new: Chris goes over how they extract functionality into standalone pieces that can be used in both their old and new engine, so that they can better repurpose the best parts while not completely duplicating anything. This sounds like a good way to begin a new design system if you already have one (or something like one).