Data is a Brick

I have often used the analogy of a brick to describe the ideal user interface. A brick is immediately understood by everyone, easy to use, and can serve multiple purposes: a tool, a weapon, a paper weight, to hold up the end of a desk, build a wall, etc. But the brick idea extends to data as well.

After a discussion with some of my colleagues about “data hydration”, it occurred to me that the metaphor (and therefore the premise) is wrong. Hydration, sponges, and vessels are not part of the real metaphor (in fact, try to find examples or definitions of data hydration online). There are no idioms in the programming vernacular that match the hydration metaphor. Data is NOT a sponge. Data is a brick - it has structure and is immutable. While it can serve many purposes, it is still just a brick.

We already have the “assembly” in our vocabulary, so let’s extend that to the example of an assembly line. The function of an assembly line is to take a series of parts and “assemble” them. Our colloquial assembly does essentially the same thing. It is a set of blueprints (class definitions) for assembling bricks (data) into a cohesive and meaningful structure. No H2O involved.