💡The Bitloops (Big Idea) Vision
So why did we decide to build Bitloops? What’s the ultimate vision behind Bitloops?
Below is a detailed description of why seven engineers decided to leave their cushy jobs and build Bitloops. It describes the vision along with some of the expected features, benefits and value proposition.
Why? Revolutionize developer productivity
Whenever we speak to people working in Product & Tech, the number one issue is always: “we are unable to release new features quickly”. No matter who you speak to, this is the number one cause of concern, anxiety, employee churn and tension between teams.
To understand this issue better, its important to distinguish developer productivity at the start of a project, and developer productivity once an application reaches a certain size or complexity.In general, developer productivity is not an issue when starting a new project. When there is no code, software developers (adjusted for experience level of course), are able to create a new feature very quickly. They simply think about the problem a bit, write out some code, try to run it, debug it, and soon enough, the feature is up and running. In fact, a good software developer could even take that code, and add 2 or 3 more features to it at a relatively quick pace.
However, once a developer gets past those 4 or 5 initial features, or they hire a couple of people to help out, they realize just how much of a mess the source code is, and how difficult it is to add new features. The new hires don’t understand the source code, and in fact, even the original software developer doesn’t understand how or why some code is written in a certain way, or why they’re getting a specific error or behavior that was not expected.
The truth is that for 99% of companies out there, developer productivity falls dramatically as applications become larger and more complex. The Bitloops team discussed at lengths the possible root causes, and also spoke to friends and (ex-) colleagues across the world working in Product & Tech, and identified several reasons why this happens:
- Larger / more complex applications require more resources to manage all the details, causing a slow-down in communication and decision making
- With additional resources, the feature vision is idealized by 1 person, but implemented by another, and the communication between these two individuals may go through several people, leading to unclear requirements
- Resources are hired and onboarded without proper training or access to documentation that allows them to understand the system adequately
- Documentation is mostly out-of date given the increasing priorities and need to ship features faster
- The increasing backlog of priorities leads to poor or no refactoring, which leads to ever increasing technical debt
- The strongly decreasing average age of a developer, given the strong increase in interest in this industry in the past 10 years, which leads to a significantly lower average experience level
- Poor coding practices and a lack of understanding of industry best practices and methodologies
- Badly written and/or frequently changing business requirements
Subsequently, through several internal discussions, and over 100 chats/interviews with developers across the world (thank you all so much for your time and feedback), we basically came to the realization that the best way to solve this issue was to ensure applications where designed as best as possible (given the knowledge available at the time of design), as well as flexible and maintainable as possible to allow for iterations, changes and extensions as quickly as possible.
Of course, companies that want to improve developer velocity can and should improve many other aspects relating to the software development process, including documentation, training, recruitment, mentoring and communication flow. However, if they do all this, and then end up designing poorly structured software architectures, or writing bad code, they’ll end up with the same problem: poor developer productivity
Give Developers what they want
During our discussions with several developers, it also became very clear that software engineers today are very frustrated with how software development is managed across organizations. In essence, developers feel:
- Undervalued by business as they have no idea about anything technology related
- Overworked with increasing number of feature requirements, when Business does not understanding the difficulty in implementing said features
- Bored as most of their time is spent in meetings, debugging code, waiting for test or clarifying requirements with Business, and not in actuallying thinking and solving problems
The culmination of these issues is that developers feel unproductive, and in fact, a StackOverflow report in March 2022 clearly shows that feeling unproductive at work was number one (45%) among the factors that cause unhappiness - even above salary - amongst software developers.
Of course, improving developer productivity alone will not make all developers happy, but it most certainly will contribute to greater self esteem, greater appreciation by other stakeholders and a general improvement in developer happiness, which ultimately leads to more productive developers.
The big idea!
Given all this, the Bitloops team started idealizing a tool that would empower developers to build applications that could grow in size and complexity, but would remain understandable, maintainable and flexible.
The vision is that you start building your application, with the limited information you have at the beginning, but do so in a structured way that allows you to easily refactor, change and improve the code base as you learn more about your domain. Moreover, when you hire additional developers, it should be relatively easy for them to understand your source code, understand the tests, and start contributing ASAP with new features.
During our research we also understood that a major pain point most companies go through during their growth is the need to move from a monolith to a microservices architecture. Most applications start off as a simple monolith, and if designed well end up becoming a modular monolith where the code is segmented into individual feature modules that allow several teams to work concurrently on the same application. Subsequently, as an application scales and becomes more complex, there is normally a need to move towards a microservices architecture so that specific features can be scaled independently, and new features can be quickly added. This transition is particularly hard (and costly), if the system has not been adequately designed and coded. We wanted to build a system that would decrease coupling, increase cohesion and drive adequate separation of concerns to make it very easy (maybe with just a couple of clicks) to convert a modular monolith into a microservices architecture.
After long deliberations, we realized that to achieve all this we needed a higher-level language that was easy to write, read and change. Moreover, the language needed to be specific enough to drive developers to follow certain patterns that would provide the structure and clarity required, but flexible enough to allow creativity and refactoring to flourish.
And this is how Bitloops Language was born! A high-productivity, 4th generation programming language that drives developers to build well designed code and high-quality software
Bitloops Benefits
There are several benefits in using the Bitloops: it simplifies programming, translates into performante languages, creates boilerplate code, reduces probability of bugs, enables transition from modular monolith to microservices architecture, offers integrated backend services, deploys to production with a single command and lots more. Let's go over how each of these benefits emerges.
🙌 Simplifies programming
As a higher-level language, Bitloops Language is easy to read, write and change. It follows the object-oriented programming paradigm, but goes a step further and drives developers to think about their domain in terms of value objects, entities and aggregates.
Leveraging best practices in software design such as domain-driven design, Bitloops Language requires developers to define their objects in specific ways that ensure encapsulation and separation of concern.
Furthermore, following best practices in software architecture such as layered or hexagonal architecture, the Bitloops Language drives developers to design the domain logic separately from the application layer, which drives loose coupling and high cohesion, two other important factors in software development.
All in all, Bitloops Language is simply easier to read and understand, which makes it very powerful for onboarding new team members and making changes to the code base.
✍🏽 Transpiles into other languages
Every programming language has its pros and cons. In general, the harder the language is to learn and write, the harder it is to change, but the more performante (and therefore cheaper to run) it is. Languages that are easier to read and write are generally easier to change, but performance can sometimes be negatively affected (there are exceptions of course).
Bitloops is a transpiled language, meaning it transplites (translates) into other programming languages that run on a server. Right now we offer TypeScript as the output language, however, we do aim to offer other options such as C++ or Java in the future.
Bitloops will not be the best language for every single software requirement, but it is a very good solution for any software that has complex business logic and frequently changing requirements such as consumer apps or Software-as-a-Service. In fact, with Bitloops developers can finally have their cake and eat it as it provides the ease of use (write, read, change), as well as the performance of a low-level language.