Maintaining a Component Library at Scale
Before we dive into the topic, a little bit of context would be necessary because we're going to talk about a solution that works for our organisation. Having context helps you in deciding if and what would work in your situation.
So at the company I currently work for, we cater to a big audience. As a big company, we also have a big stake in IT solutions to get our businesses running. A lot of our software and tooling is build in house.
In fact, there's a whole department of IT specialists, collaborating on digital products. To accelerate our web product development, we've built and are maintaining our own component library.
We're using VueJS as our framework of choice, and yes, there are off the shelf solutions we could apply. But we didn't. And we think we have very good reasons for doing the heavy lifting ourselves.
We have a need for more specialised components.
We believe that a component library should match the brand and not the other way around.
We know our customers better than from the perspective of a generic set of components.
Design System
Our component library is an essential part of our design system. It helps us with aligning designers, developers and other stakeholders in teaching us to speak the same language. The goal of the design system is facilitate with quickly building applications according to the rules we've set out.
Putting the customer first 🏆
Our philosophy is to put the customer first. A way of supporting that is by providing an Omni Channel Experience. This means that from a customers' perspective, you have the most seamless interaction with any of our products or service because you are dealing with the company as one entity. To make that as seamless as possible, it just makes sense to use and reuse components and their interactions as much as possible. Because for the online part at least, you then have a familiar interface to deal with.
So we've established that a component library makes absolute sense and we even encourage to reuse not just visual components, but also more elaborate interactions, strengthening the Omni Channel Experience across our solutions.
Now it takes effort to build and maintain a component library. You could do this with a dedicated internal team, working around the clock on adding new features via requests and maintaining the product.
A distributed approach
We did something else. We took a distributed approach, where every team using the library is also part of that team in a way. In practice, what could happen is that you work on a feature and simply use a component to fulfil the business need. Or you find that a component is not capable of meeting requirements. In that case, what happens is that a developer modifies (expands) the component and uses the latest version to fulfil the feature. The library is being improved based on business features.
We believe this benefits us, because of a couple of reasons that fit within our companies' philosophy.
Having this setup establishes an investment in the library. Since you're using and building it, you have a responsibility to keep it purring like a happy kitten.
A distributed approach also ensures that knowledge is distributed across the development teams.
We have short feature cycles on the library, because as a developer you have the freedom and responsibility to modify the library when needed. There's no dependancy on another team.
These small increments are immediately released, which means that other teams immediately benefit from any improvements.
Rules and guidelines 🎲
If you want people to play, you need to set clear rules. And we did. The most important one is about communication. Share upcoming changes, issues you're facing and share successes!
If you're adding features or new component, also ensure the reusability of the addition. Since you're adding from a business feature point of view, it is likely you need to do some decoupling of the feature and underlying component.
To ensure the quality we set out to automate as much as we can, which seems obvious if you think about it. Anything repetitive should be automated. This doesn't only save time, but it also serves as a more objective way of measuring additions. It's less opinionated than sifting through a pull request when somebody has a bad day.
So this works really well! We're improving our component library on a daily basis, by small increments that everybody can immediately use. This is great!
What about ..? 🤔
There is, of course, a caveat. What happens when you need to work on bigger topics? We do need to upgrade dependencies every now and then and that is something that doesn't fit in with the concept of improving by adding features. There's also the DevOps related activities that fall in similar categories, or even adding or replacing tooling solutions. These are no daily challenges, but they do pop up on a regular basis. Turns out, we have a fitting solution for that as well.
We are encouraged to spend 30% of our time on stuff that is not team related but helps the company in the long run. That is a generous amount of time, if you think about it. What we see happening is that people feel responsible for the library. So when some of these issues arise, people seek each other out to solve the issues. The nice part is that people from completely different teams are seeking each other out to work on a common task from their own interest and motivation, which is awesome.
We've now been employing this way of working for a couple of years. During that time we've seen the library grow and tooling come and go. The distributed model works for us!