Raising Productivity: Distributed Autonomous Web Development Teams
Getting the most out of a distributed workforce with independent components and Bit
The effects of Covid-19, once perceived as no more than a temporary disruption to our daily lives, are now acknowledged as here to stay. This new realization has pushed companies to reevaluate the way they operate and move away from methodologies and tools that serve as “colocated work replacements” to those that fully embrace this new reality.
This full embracement is not manifested as ‘remote work,’ with headquarters to be remote from, but rather as a completely distributed workforce where the “center” is absent.
In this blog post, we’ll explore Bit (Github), a tool that manages independent components to enable effective and productive collaboration in distributed web development teams.
Why Go for a Distributed Workforce Model?
Autonomy raises productivity and satisfaction
A distributed workforce model enables the highest autonomy for developers and teams. That is crucial as autonomy in the workplace has been shown to raise productivity and satisfaction (see footnotes). That’s true for humans, but that’s also true for developers.
For developers, it’s not only choosing their working hours or work environment but also having full ownership over a set of features or components, from creation to delivery.
A “certificate“ of a bottleneck-free collaboration
A distributed workforce is not only a means to an end but also an indication of highly effective teamwork. Working independently and asynchronously means that a company has achieved a bottleneck-free collaboration. Every developer or team can move forward freely, unhindered by the lack of availability of other developers or their products.
In other words — if your team or company cannot make the transition to a fully distributed workforce, then it’s fair to speculate you encounter blockers more frequently than you’d hoped for.
Autonomous Frontend Teams: Independent Components vs Micro Frontends
One methodology or architectural style immediately comes to mind when thinking of collaboration between autonomous frontend teams — that is, Micro Frontends.
In a nutshell, Micro frontends are a way to compose frontends using small, independent, and manageable pieces, as opposed to one large monolith.
The term “Micro Frontends” has many unwanted connotations and conceptual limitations. It derives much of its meaning by analogy to microservices — an analogy that should only be taken as an incomplete comparison of the two. Therefore, I will be using the term “independent components” to signify anything from a simple UI primitive to a full page.
Independent components are components that are source-controlled, documented, tested, and delivered — independently.
As mentioned earlier, these components are not limited to simple UI elements. To make that point as clear as possible — here are a few examples of such components:
- Elementary UI components — for example, a button — usually, part of a design system
- Compositions or “widgets” — for example, a date-picker
- Data-connected components — for example, an address form with auto-fill
- Pages — for example, a product page
- Data/logic modules — for example, a custom React hook that handles data fetching
There are various ways to integrate independent components into a single UI but that is not the focus of this article — instead, we’ll discuss the isolating, testing, sharing, and managing of components.
Managing Independent Components with Bit — An Introduction
Once a Bit workspace is initialized in your project, each component can be source-controlled independently. That is the beginning of freedom for you and your components.
Bit’s source control doesn’t replace your project-level source control but adds another one, on top of it. This new layer understands what a component is and what its boundaries are.
Whenever a component is ready to be delivered, Bit builds it, tests it in its isolated environment, packages it, and publishes it to its relevant scope on Bit’s component hub.
Components, published on Bit are available to be examined and installed by others. That’s Bit, in a nutshell.
But why talk when we can walk ?— here’s a quick demo (for a more detailed one — see here)
I’ll create a new create-react-app project with TypeScript:
$ npx create-react-app jokes-app --template typescriptI’ll then create a simple button:
Remember that component could be any feature — large or small, “smart” or “dumb”
|-- src
|-- button
|-- button.tsx
|-- button.module.scss
|-- button.spec.js
|-- button.tsI’ll now start tracking this Button component as an independent feature. Once that component is published to Bit’s component hub, it can be used everywhere.
// initialize a Bit workspace
$ bit init// track the Button component
$ bit add src/button// set a compiler (giving it what it needs to be independent)
$ bit import bit.envs/compilers/react-typescript --compiler// build, test and package it
$ bit tag button// share it to a collection/ deliver it to other projects
// first, you'll need to create a scope or collection in Bit.dev
$ bit export eden.jokes-app
Working as Autonomous Teams: Bit Features and Principles
Documentation
Real-time exchange of knowledge is limited by the availability of either side of that exchange. That is a frequent source of blockers to progress.
These sorts of ephemeral conversations often repeat themselves with other teammates as they are not documented.
Independent developers or teams make use of Bit to document their own features, their own components. That’s done in two way:
- Bit auto-generates documentation by parsing the code
- Bit identifies the README file in the component directory and renders it in the component page, on Bit’s component hub
API-first Approach
Another way to eliminate impediments caused by lack of information is by obviating the need for that information, in the first place. Independent components with a clear API enable just that. They can be treated as “black boxes” — their implementation is simply irrelevant, making them simple and easy to use.
“Bite-Size” Codebases
Becoming an expert on a small and decoupled project is much easier than dealing with a huge monolith. That’s even more critical for novice developers or when onboarding newly-hired developers. They can start working independently right away as they only have to deal with a single component.
Independent CI and Delivery
To ensure each frontend gets its own independent and fast build process, Bit also provides a unique CI/CD process that is 100% component-driven, meaning that different teams can safely integrate changes without having to wait, fight over master, or break anything. Developers can continuously and safely propagate changes to components across all affected applications.
Instead of building every monolithic project in one build process that all teams have to go through, the component-driven CI splits the build process so that it only runs on the components that changed and propagates the changes infinity up their dependency graph, to build every affected component, on every page, in every app.
Automatic Notifications
Bit integrates with Slack to notify your team or organization of “actions” made on shared components. These actions include component exports (when sharing a new or updated component), component imports (when consuming a new or updated component), and component removals.
This automation gives another level of freedom as information crucial to other developers is always shared and received when needed, even when a developer is unaware of the need to share that info.
Resources on the effects of autonomy in the workplace:
- Autonomy in Paid Work and Employee Subjective Well-Being
- Job autonomy and job satisfaction: new evidence
- Working-time autonomy as a management practice
- Autonomy Raises Productivity: An Experiment Measuring Neurophysiology
