When building software, every decision you make is influenced, if not wholly determined, by implicit and explicit constraints you have put on yourself.
Before I dive deeper, let’s define constraint:
limitation or restriction.
Here’s Wikipedia’s description in terms of mathematical constraints:
In mathematics, a constraint is a condition of an optimization problem that the solution must satisfy.
I like this; think about a constraint as an assertion to a test you are placing on your software.
Everything is a constraint
Let me give a simple example of what I mean here. When we were building Astro we knew that we wanted to implement islands architecture.
So there we have a constraint.
Must support islands architecture.
As we were talking about how to build Astro we very quickly decided to have an HTML-like language (which would become .astro) because that would allow us to detect islands usage.
However, in my memory, we didn’t talk about this as a decision we were making; we spoke about it as a requirement, something that was necessary to support islands.
This isn’t necessarily true, there have been other projects that support islands in a different way. We were implicitly constraining the design and that forced us into what became .astro.
Islands must be automatically discovered.
---
import Island from '../components/Island.jsx';
---
<Island client:load />
I say this to say: constraints are with you whether you realize it or not.
Unmasking constraints is a superpower
Given that almost all of our decisions are influenced by the implicit and explicit constraints we put on ourselves, wouldn’t it be better to just spell them out?
Take the above example with Astro’s initial design. Imagine the constraints being explicitly spelled out; in this case I think we would have arrived at the same conclusion, but this is only one of dozens of decisions that were made, and decisions that we continue to make even today.
This is where it gets fun; if you’re willing to think about constraints explicitly you have a major advantage over your competitors, because almost no one is doing this.
Even in highly successful open source projects, most people are going off of vibes. When you think more methodically about what you are doing, you have secret information they don’t have. Not because you’re smarter, because you are willing to confront your implicit biases and most people refrain from doing so.
Implicit constraints go deep
If you want to take it to another level, think about the constraints to your constraints. Remember, everything is a constraint. They are like onions. Once you reveal why you made this decision there’s likely something underneath. As a thought exercise:
- Constraint: Astro need to autodiscover islands
- So we can optimize the page for the user during the build.
- Constraint: The page need to be optimized
- Because web pages are served over network and suffer from latency.
- Constraint: Astro is a web framework, not a native app.
Whoa, that escalated quickly. Obviously we don’t need to go any deeper, Astro does need to be a web framework.
But the point being, if most people aren’t thinking about constraints, even fewer are thinking about the layers beneath.
If you’re willing to think about them, you’re going to some times find layers underneath that can be challenged. And when you do that, you have really unlocked the ability to discover new ideas that no one else is even beginning to think about.