Schrödinger's Longcat

The number of programs one could write is vaster even than the number of chess games one could play. Worse, the development of a program may never end—although with certain architecture (or lack thereof) developers might wish it. Building code that works and grows is non-trivial, and can feel as wrong as sending a newborn kitten off to work, or grafting neon signs onto the Pyramids.

Code structure should welcome improvement and adaptation, but function should appear and perform from the very first execution. In my recent experience writing marketing tools for Xyla, we frequently and successfully mated these imperatives that a continuously used and rapidly evolving product architecture be simultaneously hard and soft.

Superposition

The quantum potential that many distinct states coexist in the same space and time would appear at odds with the binary nature of computing, but we reconciled them through the following principles:

• Only one state actually manifests in any given set of user stories (in a single product deployment).
• Superpositioned code need not be written; it need only be present in the programmer's mind as a possible future that the code of the present should not preclude.

The quantum wave exists in engineers' planning, discussions, and structural decisions while each release of the code defines one collapsed state of that function.

Dead and/or Alive

The quantum perspective(s) simplify code organization by providing a context of alternate states against whose contrast the current objectives appear clearly.

/**
 * @module Longcat
 * We wanted to build a responsive drill-down data exploration
 * tool with unlimited depth (height) like a longcat.
 */

When we determined metaphorically that between the dead and live longcat(s), the dead one would be most easily used for our initial feature set, high-level organization became immediately obvious—code should be divided into:
1 . Generic Longcat code to write first

/**
 * Data set wrapper with browser-side filtering and aggregation.
 */
class Transformable {}
/**
 * Grid defining nested drill-down data set nodes.
 */
class IOGridComponent {}
/**
 * Configurable graph rendering library.
 */
class Grapher {}

2 . Dead Longcat code to write second

/**
 * Grid row displaying each node's data in an unresponsive chart.
 */
class NodeChartComponent {}

3 . Live Longcat code not to write at all until requested

/**
 * The ghost of future code haunted the project in the form of
 * generic components and configuration interfaces, such as
 * GrapherConfig. When we implemented responsive, user-customized
 * charts and combined drill-downs in persistent interactive
 * report grids, the longcat simply and naturally grew.
 */

By considering the dead longcat in morbid contrast to a live one, hierarchies and fracture lines in project organization are illuminated as branching alternatives. The most beneficial insights to come from this approach for us were:

• Analysis: Distinct sections of code to write could be identified and encapsulated using their common or differing relationships to the various potential code states, e.g. the living vs deceased longcat.

We never mixed assumptions about what data was to be displayed or how it would be rendered into generic code such as the grid layout or data transformation system.

• Synthesis: Engineers implicitly wrote code to be compatible with connections and adaptations in future sprints without sacrificing velocity or mental bandwidth, simply through awareness of potential code evolutions.

We intuitively identified configuration parameters for data transformation and graph rendering and kept them separate from code logic.

• Cooporation: The team remained synchronized and converged on the immediate common objective, since our model differentiated a singular present goal-state from all later eventualities.

Our query, data flow, and UX implementations by different engineers merged seamlessly into our first targeted set of features, and evolved rapidly into the next.

(Dis)entanglement

Ironically, by constantly considering a multiplicity of possibilities and eventualities each moment of our work was not diluted but clarified. Our consideration of the general polymorphic problem permitted us to tease out a first—but not only—concrete solution and implement it within a space of established surrounding possibilities; rather than uncertainty about the edges of our scope and what lay outside them, we saw a glimpse of the multiverse and our direction in it.

Such awareness untangled us from conflicting limitations of space and time: we were able to implement the live longcat afterward but in parallel with the dead one—which was at least nine times easier than re-animating it. Knowing the actual, the potential, and their intimacy, we delivered specific value in each wave of iteration, with infinite possibility surging round us and refracting in each release.

Photo by sergio souza

Cover photo by Josh Sorenson