A love letter to Fibery.io
Fibery was the first time I enjoyed making a subscription payment. After snoozing my nth todo in my personal Task Management workflow, I finally exceeded the free automation limit and had to upgrade to a paid plan. But I felt fine (unlike when Google tried to sell me Youtube Music Premium). A startup had created my favorite software product, and let me use it for free. I wanted to support their continued existence. In fact, I want to do more, so I’m writing this blog post to convince my friends to use it (for business not personal, I know I’m a nutcase 😛).
Fibery pitches itself as a unified “work platform” that connects disparate tools such as wiki, CRM, project management tooling. It is suitable for human scale business processes (that might otherwise use tools like Notion, Trello, or Airtable).
To fully appreciate the beauty of Fibery, however, one must go beyond arguments about business utility. One must consider the holistic approach that it represents in the landscape of software development. Not just the “what”, but the “how”.
Software is filled with jargon like “frontend”, “backend”, “client”, “server”, UI/UX, scalability, configuration, algorithms, performance, modularity, databases etc.
But I claim that an “application” fundamentally cares about one thing. An application is an entity. It is a piece of the world that you interact with. It is a piece of state.
We can think about any software application as:
That’s all.
Thinking of an application this way boils the problem down to the essential part, which is the complexity of the world itself. The complexity of an application’s core state cannot be reduced by clever designs, so it must be embraced and grappled with.
In his essays in The Mythical Man Month, Fred Brooks coined the term “essential complexity” to describe the inherent difficulty of a software problem, as opposed to the “accidental complexity” that arises from our poor design decisions. To a first approximation, I’d say that an application’s state represents the former, while the latter arises when we add ways of seeing or changing the state.
I work at a company that loves functional programming - we prefer to write as much code as we can in the form of “pure functions” from inputs to outputs, without changing any state.
A micro-example of this is that straightforward transformations of data never involve initializing mutable variables (such as lists in python, or arrays C or Java).