The Hard Thing About Abstraction
Our lives are built on abstraction. It is what allows us build things much faster than we previously could. A person, or a group of people, decides that everyone else shouldn’t need to think about the gritty details of a problem — and voila, a new layer in the stack!
This is great until someone comes along and builds on that new layer, then discovers it obfuscates a lower level detail that they need. The abstraction that was intended to be, and in many cases is, an enabler has suddenly become a hindrance. There are a few options for how abstraction builders can choose to handle this trade-off.
The simplest solution is to decide that they are targeting a narrow audience, acknowledging that they won’t be a good fit for everyone. In reality, nearly all technology is optimized for some subset of the total possible consumers. Even the most ubiquitous products are disliked by some, and don’t fit the requirements of others. Choosing where you want to exist on the spectrum from a narrow audience to a broad one is critically important when designing a product.
Another option is to break the abstraction layer into a set of smaller, modular abstractions that can be assembled in a variety of configurations. This typically enables faster iteration, and when exposed to end-users, widens the audience for the product. The downside is that you are also pushing more cognitive burden onto the end-user, forcing them to understand multiple components and how they should piece them together.
Like any early-stage company, we at Golioth have wrestled with where we fall on the “audience spectrum”. Historically, we have leaned towards a more opinionated platform, prioritizing simplicity and ease of use over letting customers adjust all the knobs. There is good reason for this approach. Golioth connects two fairly disparate technical domains, firmware and the cloud, and many of our customers have deep expertise in one, but not both. The tricky thing about this strategy is that making the firmware highly customizable and the cloud opinionated, or vice versa, results in half our users having an experience that is not catered to their current capabilities.
We could take the simple solution and decide that we are only really targeting half of the total potential audience. Perhaps we could build an incredible platform for firmware engineers who don’t want to think about the cloud. Unfortunately, our users are building products based on connecting hardware to the internet, which is no simple feat. In the early stages, they typically want to shrink scope as much as possible. If functionality is not absolutely necessary, it can wait. But down the line, their team may grow, their product may expand, and they may decide that a domain they were previously happy to consume abstractly is now an area where they need fine-grained control. Golioth needs to serve users along each step on that journey.
Over the next few weeks, we are rolling out significant updates to Golioth that give you more control over the platform. But don’t worry, the simple, streamlined experience you know and love isn’t going anywhere. Alongside these changes, we’ll also give you more insight into your usage, and if you don’t want to think about managing custom configuration, we’ll provide reasonable defaults that allow you to keep using Golioth as you always have. With these new capabilities, from prototype to production, we can’t wait to see what you will build!
Start the discussion at forum.golioth.io