How to bring back magic to software
This blog post was inspired by the Linear README
What is magic?
The magician uses the fact that a map is a projection of the territory, and that different configurations of the territory can map to the same map. A hat with a hidden compartment for a rabbit looks like an empty hat from the audience's point of view. Magicians must understand both the territory and the audience’s map, manipulating the territory while keeping the audience focused on their map to perform the trick.
How are programmers magicians?
Programmers, like magicians, create illusions with GUIs, manipulating pixel colors based on user input to make users feel they’re interacting with real "objects," such as dragging folders.
While in the magician’s case, it’s impossible operate in terms of the audience’s map—rabbits don’t appear out of nowhere, as they’re bound by the laws of physics. For programmers, however, it’s easy to forget that the "objects" in the UI are illusions for the audience’s entertainment, not affordances for the programmer to work with.
This pattern doesn't just apply to GUIs, what happens in business software is that most programmers rely on affordances or maps derived directly from business stakeholders and don't try to uncover more of the territory hidden under all those maps. I have written about this in:
- Modeling - territory first where modeling and working with the map or affordance that is the order "object" directly instead of uncovering the underlying processes that are the territory complicates of the system
- Modeling - whole first where directly modeling the affordances that are given by a stakeholder increases the overall complexity of the system.
In the early days of computing programmers had to be more cognizant of the distinction of map and territory and how to conjure up different maps in the mind of users by manipulating the territory 1 because of limited hardware resources and more importantly limited software resources. There weren't many libraries that put layers and layers of maps on the territory. What maps do is make discovering other possible maps harder. If you think about programming as sculpting by chiseling from marble, many libraries remove large portions of the marble to save time, only for programmers to later realize those pieces were essential and must be painstakingly restored.
Conclusion
If we want to bring magic back to software, we have to keep in mind the distinction of the map and the territory and not fall into the trap of believing that the map we crafted for the audience is real.
This refers to two territories: The territory of the physical computer and the territory of the thing in the real world being modeled.↩