Ad Hoc

Systems emerge, sometimes unwittingly. Unplanned, unstructured, intended only to address current needs, they evolve in fits and starts; a bit of duct tape here, a script there. Before you know it, you’re dealing with critical — and often, unmanageable — infrastructure.

I start a new Sketch file, meaning to illustrate ideas for a website’s navigation system. “I should turn this button into a symbol,” I say to myself, “so I can re-use it.” And so it begins. How much flexibility should I build into the symbol? How many variations will I be dealing with? I don’t yet know. Start simple, with just enough complexity to get the current job done. Grow from there; adjust as required. The system evolves. Edge cases are accommodated; complexity creeps in. “I’ll make a new symbol for this.” Problem solved — for now. And so, exceptions accumulate.

That said, I know the tradeoffs involved in allowing such anomalies. The time I save now will come with a price later. So I’m a mindful steward of the system. Before long, I have a file with many dozens of Sketch symbols, some quite elaborate. I’m fussy about the structure and naming of layers, but even so, I’m amazed at the complexity that ensues. Still, I now have a modular system that can illustrate a variety of situations very quickly.

In the best cases, these little ad hoc systems serve our immediate needs and then retire to a backup drive somewhere in our archives. But what if the system must continue serving future (still unspecified) needs? Then it must become more formal. Exceptions must be ironed out, or at least documented; patterns must be normalized; implicit structures concretized. (But not too much — the system must still be flexible.)

It all takes time, energy, and resources. At some point, managing the system becomes more onerous than working without one. So a careful balance must be struck and continuously re-adjusted. Constant vigilance is required: knowing how much to work on the work versus how much to work on the work that produces the work.