(A frame from "Fantasia", set to Stravinsky's "The Rite of Spring", depicting two developers arguing about serialization formats, seconds before the AI meteor hits and wipes us all out.)
---
About 20 years ago, I attended a jazz masterclass by pianist Kenny Werner. That’s where I first heard Stravinsky’s famous line:
“The more constraints one imposes, the more one frees oneself.”
Werner (and, I assume, Stravinsky) was talking about creativity—how limitations can be a catalyst for it. It’s a beautiful quote that resonates with my own experience. But recently, I’ve started thinking about it in a different way, not as something that fosters creativity, but rather as a hallmark of solid engineering.
---
The gist:
The more technical constraints I have on what I can do, the more freedom I have to not worry about breaking things, and the more confidently I can change code and behavior in the future.
---
Programming languages as built-in constraints
Languages are human inventions, and their design choices reflect certain beliefs about how code should be written.
In C, you must declare every variable’s type explicitly. That’s a constraint.
In C++, you can often use `auto` and let the compiler infer the type. In Go, you can skip some of that too, but you still need to compile before running—another constraint.
In Python? No declarations. No compilation. Just run it. If types don’t match, the interpreter will figure it out when (or if) it gets there. Amazing!
---
At first, that feels great—less ceremony, faster iteration, fewer keystrokes. But once you start working on anything bigger than a toy script, it bites back. Reading unfamiliar code becomes a chore—good luck figuring out what type that variable is supposed to be. And if you make a type-related mistake in an execution branch that isn’t covered by tests, you’ll only find out in production, because there’s no “annoying compiler” to catch these things upfront.
---
Yes, Python has type annotations, smart IDEs, and libraries like pydantic. But that sort of proves the point: as Python grew into a language for large systems, people added tools to enforce constraints—because constraints are useful. They give you freedom.
---
Same thing with serialization
Take something like Protocol Buffers: You define a schema, compile it into code, and make changes in controlled ways. Lots of work upfront!
Or you can just dump objects to JSON and move on—fast, simple, human-readable.
But then time passes. Someone adds a field, renames another, and suddenly our new code needs to read old data on disk… good luck figuring out what the old format was.
That up‑front “pain” of a strict schema gives you long‑term freedom: easier debugging, safer migrations, faster changes, and fewer surprises in production.
---
Stravinsky for software engineers
So here’s my takeaway:
The more constraints we embrace early on, the freer we are later.
Languages with stricter typing, serialization formats with schemas, databases with defined structure—these may feel like a burden while writing code.
But those constraints are what make future maintenance, debugging, and extension so much easier.
