# Do One Thing And Do It Well: A Reapplication Of The UNIX Tool Philosophy **URL:** \ **Category:** Community Chatroom (DISCUSSION)\ **Created:** [May 3, 2021, 1:19am UTC](https://gov.bancor.network/t/do-one-thing-and-do-it-well-a-reapplication-of-the-unix-tool-philosophy/1977 "2021-05-03T01:19:21Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![ccc](https://dub1.discourse-cdn.com/flex013/user_avatar/gov.bancor.network/ccc/32/3214_2.png) [@ccc](https://gov.bancor.network/u/ccc)\ **Post date:** [May 3, 2021, 1:19am UTC](https://gov.bancor.network/t/do-one-thing-and-do-it-well-a-reapplication-of-the-unix-tool-philosophy/1977/1 "2021-05-03T01:19:21Z")
Hello fellow “Bancorians” (can we adopt that term? It’s _cute_ 😁). I’ve expressed several times that I think we should do one thing and do it well. I think it’s high time I fully explain mysmellf, and lay it out (for anyone with an interest) _why_ I say that. As one of the core pillars of my mind, I’ve adopted the _UNIX Philosophy_; this has helped me greatly in my work, as it _encourages narrow scope by default_. Firstly, what is the “UNIX Philosophy”? In a nutshell, it’s exactly what I’ve been saying; _do one thing and do it well_. It’s a tools-oriented philosophy that essentially boils down to, build primitives that you can combine in myriad ways to complete a task. If you find that you use a particular pattern or workflow often, package it into a “higher-order primitive”. How is this useful? Building _highly composable primitives_ confers several advantages to a system, among them: - It allows developers and users to experiment with different compositions to complete different tasks or suit different purposes, share the best ones, and even package them into full programs. - It saves the _hecc_ out of developer time by abstracting away functionalities and dividing up the work; a developer of a primitive only has to worry about accomplishing one thing and optimizing the _hecc_ out of that, whereas a higher-level developer doesn’t have to worry about lower-level implementation, it’s just _there_ and it _does its job_ and they can focus on _their_ one thing. So how does this relate to Bancor? Well, we are a _highly composable primitive_ that does exactly one thing: swap one token for another _while preserving maximum value, **now** _. - We allow DEX/dApp developers to abstract away the issue of dealing with market inefficiencies. - DEX/dApp developers allow us to abstract away the issue of handling trades directly; in my ideal world, we wouldn’t _need_ to have a swap function on our web interface; I think that function _should_ be handled by someone else’s dApp working as a frontend, and our web interface should exist solely for the purposes of staking BNT/vBNT/TKN and [viewing live data about the protocol](https://gov.bancor.network/t/live-interactive-trading-charts/1788). - This attitude would prove to be profitable, as just getting plugged into the backend of many DEXes exposes us to many, _many_ times more users than we could ever hope to attract in and of ourselves, [even with marketing](https://gov.bancor.network/t/automatically-allocate-2-of-fees-to-marketing/1693), and offloads a _lot_ of development time and resource expenditure. - We can compose _other protocols_ into our DAO’s systems and build amazing functionalities, such as [rewarding voting](https://gov.bancor.network/t/how-to-increase-voter-turnout/1933), with very little effort at all. The DAO could even hold a stake in other protocol’s DAOs. The Bancor protocol express a simple relationship: `A >>= B >>= C` Which is to say, "`A` binds (aka maps) to `B` binds to `C`", where `A` is the input token, `B` is the Bancor Network Token, and `C` is the output token. Let’s not spend resources burying that simple, core functionality under a heap of detail-related fluff that we could easily let someone else handle. In my ideal world, we wouldn’t really need to have devs; the protocol would be automated to the point that governance decisions would just _happen_ and the DAO would be totally self-contained and would just _exist_. That’s not to say I don’t like devs! But a developer’s job is to _automate_, and we want to spend as little time (and money) automating as little as possible, and that means keeping a narrow scope and making that our sole, laser focus. I’d like to have some discussion on this topic of _philosophy_, so please share your thoughts.