How Unix philosophy helps explain Unleash’s design choices
When I first joined Unleash, one of the things that stuck in my mind was the idea of “focus.”
Earlier experiences taught me to expect a lot of context switching from meetings and rapidly changing priorities. Hearing “we want you to just focus on your task,” was strange.
And while it was a breath of fresh air, I was a bit skeptical. I’ve found that, in practice, it’s really difficult to hold on to principles that enforce focus.
Whatever your intentions, competition in a niche market can force you to chase priorities, anyway. This means changing focuses and more meetings to distill which focus is the right focus of the moment.
Over time, Unleash has shown me that there are techniques to make sure this doesn’t happen. This is mostly thanks to good prioritization, plus avoiding the trap of delivering more and more features.
The idea is that we develop the right thing, and we develop it right. This won’t come from pure luck, but from iterations, feedback loops, and going back to the board to do better. Sometimes this means dropping a solution because we’ve learned something new.
What I’ve found is that Unleash really does embrace design thinking, specifically using double diamond design. It fits really well with Unix philosophy.
Applying Unix philosophy to Unleash
Pretty early at Unleash, I saw this way of working firsthand. Our management decided to drop some big ideas for Unleash.
They had discovered some obstacles that got in the way and made the ideas expensive to implement. Instead, we either prioritized foundational work, or decided that paying technical debt was worth it to stay true to our product.
My colleague Mateusz Kwasniewski explained Unix philosophy in an internal presentation. I hadn’t heard of it before, but it did a good job explaining why Unleash’s design approach worked so well.
To illustrate, he brought up common Unix commands such as Is or cat. Isolated, they’re really simple and do just one thing: Is lists files and directories, while cat outputs file contents.
However, the two can be combined through techniques like pipes (|) or output redirection (>). This leads to a lot more powerful stuff.
In other words, you’re using existing tools to make small tweaks to get the most of what you already have.
I’m a big fan of Linux operating systems. I’ve been using them as my main development platform for more than a decade. So Mateusz’s talk really piqued my interest.
We realized that Unix’s principle of doing one thing and doing one thing right was a great way to describe Unleash’s design approach.
In fact, Unix philosophy actually has three design considerations. Here’s how we see them reflected in Unleash:
- Do one thing, and do it well. We want to be the best feature flag system. All we build in Unleash should improve on those flags.
- Expect the output of every program to become the input of another. We prioritize integrations over creating a tool that is stretched too thin.
- Design and build software–even operating systems–to be tried early. We dogfood our own product. We try to make our release cycle fluent and short for our customers.
Let’s dive in a little deeper.
Why is Unleash such a good fit for Unix philosophy?
Unix philosophy is a great way to describe Unleash’s thinking. But why are we such a good fit in the first place?
First, as we’ve already talked about, the idea of focus–do one thing and do it right–was already part of our company’s culture. It helps us narrow down the scope of Unleash. It also frees us to work with other tools to complement Unleash.
Our flexibility aligns well with the second point of Unix philosophy. We don’t want to reinvent the wheel.
Instead, we prioritize integrations. You can see this in, for example, our addons.
Users like you are able to send data to other monitoring tools like Datadog. You can relay data into Google Analytics for A/B testing, or receive feature flag update notifications in Slack or Teams. You can even create your own integrations using webhooks.
Plus, our APIs are publicly available in Open API format. Our entire UI is built on top of this API.
This means that Unleash API is truly open. Users like you can create your own user interface at will. You can integrate Unleash into any application that can talk to an HTTP endpoint.
For the third point: Unleash as a product enables teams to iterate fast and gather quick feedback from their users. We also use it ourselves
This gives us a quick feedback loop from our customers. We can then quickly adapt our course while staying focused on what Unleash does well.
If your background is similar to mine, digging into Unix philosophy can seem difficult.
You can think of it as a virtuous cycle:
- Focus brings more focus.
- Integrating with other tools increases our reach and reduces our scope.
- Instant feedback helps us improve our product.
- Using our own product helps us empathize with our customer pain points.
And, ultimately, releasing features early and keeping focused on user needs means our customers stay happy.