Maintaining a Component Library at Scale

Good afternoon, everybody. As you can see, it's a big screen. It's really super bright. My name is Joran. I work for Jumbo, a grocery chain in the Netherlands.

Quickly, who is from the Netherlands or from Belgium? Who does their shopping at Albert Heijn? We have some work there, but we'll get there. We are a grocery chain in the Netherlands or Belgium. I am going to talk about if this thing works. It does. About LEGOs. But actually, a components library. We did a thing at our organization, and I wanted to share our story with you. Bear in mind that this might not be the perfect solution for you because you have a different organization, different needs, and a different environment, but it works for us. I hope that I can at least share it through our journey and give you some inspiration to take home.

As I said, we are a grocery chain in the Netherlands. I'll skip through this slide because it's just 10 minutes. It's a short amount. In order to do our e-commerce solution and all of our in-house products, we have a Jumbo tech campus where we have over 400 developers working and they work on all our digital solutions. That's not just the e-commerce, it's also the machine learning stuff, the data lakes, everything, but we also do web and we also do frontend, fortunately. That's where I come in as well.

What we at Jumbo value highly is the omnichannel experience. That means for us, at least, that we put the customer first. We think that's really important for us as an organization because from a customer perspective, you're dealing with Jumbo and not necessarily Web Team A or not necessarily a store representative. Everything that is coming from us should be, or should feel at least as familiar to you as it is, it's the one big part. This omnichannel experience is really important to us and in order to help us in facilitating an omnichannel experience, we did something that a lot of people do. We built a design system and our design system is called Kompas, which is Dutch for compas. I hope that translates well. We did a good job there, I think. But this helps us in making good decisions and how we are designing and developing our products. A little bit of background information about our component library, and again, I won't go into detail because you're not interested in our view setup, but it is built in Vue Storybook for documenting our resources.

We have a couple of actions as well, and I see Chromatic is there, so those people should be happy at their stand. Same company. So we use that as well.

Our component library, we built that thing from scratch because it makes sense to us in order to deliver our highly specific features. Now, if you build a component library from scratch, that takes a lot of time and effort we made a decision to not go with a dedicated team, because the simple reason, or the assumption actually is that that would introduce a large bottleneck for our entire organization. And that's something that we want to prevent. We want to be able to have our teams move as fast as possible because we want to get features out the door so that customers can order more groceries online. So no dedicated team. And what we did do, and I'll explain this in a bit, we took a distributed approach. And for us, that meant that everybody who uses the Component Library is able to contribute to the Component Library. So let's explain these benefits that we see, or that we saw at least. And the first is, and I think this is the most important one, and is still valid to this very day, that everybody who contributes to a library has some sort of a sense of investment or some nurturing, what you would call it. Something that you want to take care of this, right? Because you own it, you build it, you maintain it, so it's yours, and you feel some sort of investment, which I think is the most important thing.

The other thing as a benefit is that it happens sometimes that people leave your company. And what you don't want is that they take all their knowledge, their highly specific knowledge of the Component Library with them. So with distributed contributions, you also have distributed knowledge. That's our assumption. And the next thing is that if you have all of these front-end developers contributing, then you have a massive team who is helping you in delivering features. So this is also a good thing. And lastly, the last benefit that we saw is that every increment or everything that you add to the Component Library is immediately usable by all of those other teams. This makes product owners very happy, and we want to keep them happy to have sensible sprints. Let's see what's next.

Yeah, this is also very important. So if you have all of these contributors on your codebase, you need to set some rules. We basically said that if you want people to play your game, you need to have a clear set of rules so that everybody is actually playing the same game, and that it's clear what can be done and what cannot be done. And we started out with a couple of simple ones. It's very straightforward, I guess. You need to communicate upfront what you're going to be changing on the Component Library, make sure that it is reusable as a component and not highly specific to your team's needs, and keep it as simple as possible. And this worked very well for us. So we are very happy, we're working, we're working, we're growing in teams and complexity, and then stuff happens.

We encountered a couple of snags along the way, which slowly started to pile up until a point where we needed to address them. You can read about them. One of the examples is a major upgrade from Vue 2 to Vue 3. It happens in every framework or library that you have to do some maintenance. And this was not addressed by business features. So there was a sort of a problem. And if you have a problem, you need to find a way to fix this.

So we started to revisit, again, the idea of a dedicated team, because it also has some benefits. Let's see, I am for time, but this is fine. So the centralized and decentralized approach, they both have their drawbacks and their benefits. So some of the drawbacks are listed here. So this means that our decentralized had no clear ownership or direction. And they also have some benefits. So the decentralized is very fast. And the centralized has a very clear vision. And we think that vision is also highly important.

So what did we do? Well, we had to choose, didn't we? Well, actually, we chose nothing. We chose a hybrid solution where we are now currently in the works of investigating this new model. And we have sort of a hybrid approach where we still keep the teams contributing to the component library, but they have vision and guidance from a central team. That is basically sort of a shepherd of the component library. So they guard the long-term vision, they guards the quality. And at the same time, we have all of those teams who are still able to contribute with high speed so that we are still able to develop in a proper way. That's how we do it. And I wanted to end this with sort of the final takeaway. If you take nothing away from this talk, then please bear with me, because this is basically what it's all about. The process we started out with worked for us in the beginning, and we noticed over time that that process needed changing. What I'd like to give away should be obvious, I hope, but if there is something that doesn't work for you, then please change the process or change the way you do things to make sure that you actually end up with a process that fits within your organization or your team. I'm doing very well with time, so I'd like to thank you. It's been awesome being here and talking to all of these people.