Squeezing Juice from Constraints
..and why the best design solutions are often already there
This is just a first draft of something that could become an essay. Comments and questions are appreciated.
The more you know about your the environment’s constraints and affordances, the more “juice you can squeeze out of it” so to speak. Often times if you look more closely, your environment provides them “for free”.
In Alexander’s terms, this is about deeply observing the forces already at play in a context. When you understand what the environment naturally affords—existing patterns of movement, social dynamics, material properties, light, structure—you can work with these rather than against them. The best patterns don’t impose artificial solutions but reveal and amplify what’s already latent in the situation.
This applies to designing programming languages…
Dynamicland is a research project to invent a new form of computing in which people participate in the physical world instead of navigating simulated virtual worlds.
One of our discoveries is that leveraging the physical world radically reduces complexity. Tasks that might conventionally require “apps” and “codebases” can be done with a few pages of simple, readable programs. Computational activities make heavy use of physical and social mechanisms, so the parts that require actual computation can be small and high-leverage.1
…and hacking systems:
Hacks are both invented and discovered. More specifically, the underlying vulnerability is discovered, then the exploit is invented. Both words are used, but I prefer “discovered” since it reinforces the notion that the capability is latent in the system even before anyone realizes that it’s there.2
What initially got me thinking about this was reading Daniel Jackson’s book “The Essence of Software” which introduced me to the idea of “conceptual design”.
How does conceptual design help to find a form for a given context?
My first guess would be that it anticipates how a user might use the software in unintended ways. The definition would work if the tool were the form and the context were the user.
But now that I thought about it more deeply, I realized that it isn’t about the tool either.
The actual bridge between these ideas could be that good conceptual design helps you identify what “form” (in software) appropriately fits a given “context” (the user’s needs, workflow, existing mental models). So in my framing the concept would be the form, and the user’s actual practices, goals, and environment would be the context. A well-designed concept achieves “goodness of fit” between these.
Any math book is just a collection of DSLs mathematicians invented given their constraints. Back in the days, they only had pencil and paper, so they needed to work with symbolic notation. Now, we have access to computers.
Whenever I fail to adopt a practice, it’s because the workflow/concept didn’t fit my actual practices, goals and environment.
How do concepts mitigate the risk of misfit?
You can break down software into familiar concepts providing commonality across contexts. The misfits that are learned in one context for a concept usually apply in another. Then, you will only need to deal with concepts where you are not certain whether it’s a potential misfit or not. For example, …