The Backyard Quarry: Turning Rocks Into Data
Source: Dev.to
Another round of tech layoffs rolled through the industry recently, and I was one of the people caught in it.
If you’ve worked in tech for any length of time, you know the routine that follows: update the résumé, reach out to contacts, scroll job boards, and try to figure out which technologies the market is currently excited about and which ones have quietly drifted into irrelevance.
After a few days of that cycle, I found myself spending more time outside than in front of a laptop. One afternoon, walking around the yard, I noticed something interesting: my backyard contains a surprisingly large dataset.
The Unexpected Dataset
My backyard is filled with rocks of all shapes and sizes:
- Some are the size of peas.
- Others are roughly the size of a car engine.
- A few fall somewhere in the unsettling range between “wheelbarrow recommended” and “this probably requires heavy machinery.”
Naturally, I had the same thought many people eventually have when staring at a large pile of rocks: I could probably sell these. A small stand near the road, a few piles sorted by size, maybe a sign that says “Landscaping Rock.” It’s not exactly a venture‑backed startup, but stranger side businesses have existed.
Unfortunately, engineers have a well‑known weakness: we rarely do things the simple way. If I was going to sell rocks, I wasn’t just going to pile them on a table—I was going to build a system.
From Rocks to Records
The moment you start thinking about the rocks as inventory, a familiar set of questions appears:
- How many rocks are there?
- What kinds?
- Which ones are small decorative stones and which ones fall firmly into what I’ve started calling Engine Block Class?
Like many real‑world datasets, this one has significant variability. Some objects are a few grams; others weigh enough to require careful lifting technique and a brief internal conversation about life choices. At a glance, the dataset looks chaotic, but underneath the chaos are patterns: different sizes, shapes, colors, and geological types. Some rocks are smooth river stones; others are jagged fragments that look like they escaped from a small landslide.
If you squint a little, you start to see the outlines of something familiar to anyone who works with data systems—a collection of physical objects that could be represented as structured records.
Designing a Digital Twin
In theory, selling rocks is simple:
- Collect rocks.
- Put them in a pile.
- Wait for someone to stop their car and decide they want landscaping material.
But once you start thinking about it from an engineering perspective, the questions multiply:
- Should each rock have an identifier?
- Should there be photographs?
- Should the system track weight or dimensions?
- What about classification? (Pebble Class, Wheelbarrow Class, Engine Block Class, etc.)
Conceptually, a record for each rock might look like this:
rock_id: # unique identifier
weight: # in grams or kilograms
dimensions: # length × width × height
color: # descriptive or hex code
rock_type: # e.g., river stone, basalt, limestone
location_found:# GPS coordinates or yard zone
status: # e.g., in stock, sold, reserved
Each rock in the yard becomes a digital object—a structured record representing something in the physical world. In other words, each rock now has a digital twin. This might sound slightly ridiculous in the context of landscaping stones, but the idea is surprisingly powerful.
Across many industries, organizations face the same challenge: connecting messy physical reality with structured digital systems. Manufacturers track machine parts, museums catalog artifacts, farmers track crops, and logistics companies track inventory moving through warehouses. In each case, a physical object exists somewhere in the world, and we want to represent it in a way that software systems can understand.
The Backyard Quarry Project
Partly as a joke, and partly because it captured the spirit of the project, I named the effort The Backyard Quarry. What started as a casual observation turned into a small experiment in data modeling, object cataloging, and system design.
The dataset might be small, and the objects might be rocks, but the underlying questions are surprisingly rich:
- How do you represent physical objects in software?
- How do you capture information about them?
- How do you search and organize the resulting data?
- How do these systems scale when the number of objects grows from a few dozen to thousands—or millions?
What’s Next
Over the next few posts in this series, I’ll explore those questions by building a small system around the Backyard Quarry. Topics will include:
- Designing a schema for physical objects
- Capturing images and measurements
- Generating 3D models using photogrammetry
- Building ingestion pipelines
- Indexing and searching the dataset
All starting from a simple collection of rocks.
Conclusion
The world has no shortage of complicated engineering problems. Sometimes the best place to explore them is somewhere simpler—like a pile of rocks in the backyard. And if you happen to need a carefully documented specimen from the Backyard Quarry, inventory is currently available (though shipping may exceed the value of the rock itself).