The cardinal rule in programming is “Don’t repeat yourself,” or DRY. It says that developers should only implement a particular functionality within a project once. Doing otherwise is bad, because it introduces technical debt and potential inconsistencies.
But it only really applies within the scope of a project. If you move on to something else, it’s inevitable that you’ll write something you’d previously used in different projects, which obviously is hugely inefficient.
This is something Ran Mizrahi, co-founder of the Tel Aviv-based Bit, is intimately familiar with. When working on Wix’s development team, he scanned the entirety of its myriad of software systems for a particular piece of functionality, and noticed it had been created over 90 times. “This was a problem because whenever we’d update the API, someone would forget to update their code, and something would break.”
This lead him to think about the way we create software. Wouldn’t everything be so much easier if we could import other people’s code for the trivial stuff, leaving developers to focus on the fun, interesting challenges? Would’t it be great if we could build software with tens — if not hundreds — of small, consistent components, a bit like Lego?
Honey, I shrunk the package
Most programming languages have a package manager, allowing developers to easily import and use libraries created by other people. Python has PIP. Node has the Node Package Manager. Ruby has RubyGems.
Packages downloaded through these systems are complex, large bodies of code. It’s unlikely to find one, for example, that does something as simple as an arithmetic operation, or encoding a string into BASE64.
Bit treads a different path. This service is a hybrid of a code-hosting platform (think GitHub’s Gist), married with package manager, but only for the little stuff.
Developers can share snippets of code they feel are useful through the Bit platform. Other coders can then download and use them in their projects by running a single command in the terminal. And unlike other package managers, Bit executes snippets through a fascinating virtualization layer (more on that later).
Some of the projects on the Bit platform are, quite literally, one-liners. All of them are small. A good rule of thumb is that if you can measure the project in the tens of lines, and it takes a simple input and returns a simple output, then it’s a good fit.
That’s huge. Creating packages for any of the other package managers is often an exercise in frustration. It can take several hours to create just one package, and the process is intimidating to newcomers.
This difficulty has deterred developers from creating packages for the simple things — until now.
Scaffolded, self-documenting awesomeness
In addition to the platform, Bit also comes with a command line tool for the creation and installation of packages. Mizrahi showed me how, in literally less than five minutes, he could create a ‘bit’ function and upload it to the platform.
The code didn’t do much. It simply checked if an input variable was of a string type. It’s simple, but it’s also emblematic of what Bit is for.
Bit created a project directory, containing two files. The first contained the actual code itself. This had already been partially pre-filled with a skeleton template, which included an empty function and some blank JSDoc.
Mizrahi filled this out. Then he moved to the second file, which contained a skeleton for unit tests written using the Mocha testing framework. As before, he filled it out, and then uploaded it to the platform.
What’s interesting is that on Bit, there’s you don’t have to manually create the metadata. You don’t need to write mountains of documentation — which developers hate doing anyway — or a description. The JSDoc and unit tests are the documentation.
Unit testing is really important within Bit. The service uses it to identify quality programs, because if a program has a lot of unit tests, it’s likely the developer has considered more edge cases. These quality programs are prioritized within the service’s search results.
The road ahead
That’s where the virtualization layer comes in. The goal for this is to shift the focus from the language, but rather to what the input and output of the code snipped.