Hit enter after type your search item
Wzy Word

HERE ARE THE WORLD'S NEWS

Breaking the (developer) silos | Elin Nilsson & Raul Herbster | #LeadDevBerlin

/
/
/
725 Views
img

Hello? Hey, everyone I'm Raul, and this is Elin

We both work at Spotify Today, we want to share a story about how we view the Barix implementation platform by leveraging cross-police disciplinary teams and breaking silos Before we get started, how many times have you asked yourself questions of such as if only they had talked to each other a bit more? If only iOS and Android developers had sat down and went through the API design before implementing that! [Laughter] Or even if back-end developers had double-checked the schema with the client developers We also have those questions at Spotify

And, especially when it comes to those systems that are developed in environments For example, back in the engineers, design and system hard to be used by mobile developers, and vice versa >> An example of such a system at Spotify was our old A/B testing system that we call ABA, based on feature flagging, event logging on our clients and on our servers, and it has a web page for setting up and analysing experiments And it was built pretty exclusively by back-end developers in a data infrastructure tribe And what we notice is, as this system grew over time, this team of back-end developers were making assumptions about how things like how to set up feature flags, and how to run tests that didn't really work on the platforms that ABA was supposed to support – in particular for mobile

And since we like running experiments at Spotify, we realised we had to do something about this, and we decided to sit down and rebuild our experimentation platform And now, given that we have this system already that made us go, if they would only talk to each other, we figured why not take everyone and put them in the same team and have them work on it together We put together a cross-disciplinary team to solve this problem, so we made sure we had back-end engineers, data engineers, web, mobile, you name it, to build a better system than ABA And both me and Raul worked on one of these teams as mobile engineers and we built something we called remote configuration Remote configuration was a replacement for the feature-flagging mechanism within the previous system

It revolves around remotely configurable properties of aspects, our applications, our servers, and by changing the values that those properties can have, it allowed us to compare the effects that this had on our Spotify users and do experimentation With that, we learned a lot in working in this team, and we wanted to share some lessons and learning about working in cross-disciplinary teams to build better software >> So, the first thing that we did was to leverage the power of common abstractions So, we start out by sketching the full system design, and then interface between the clients and the back-end Given the background of our engineers in the team, the only way we could do that was by having common abstractions for the problem's scope so that we could communicate efficiently without getting stuck on implementation details or some specifics of the disciplines

White boarding and sketching design was important here for us, because it led us to share commonly the same of what we were building together We thought we needed to share discipline-specific expertise For example, one time, we found ourselves asking when and how we should update the values for the configuration properties Then we had the concept of secession, like the abstract concept Updating the s values mean that the UI wouldn't change while the user was using our app

On mobile, the session was tied to the life cycle of the app On the web, they really didn't have a life cycle but they could see when the user was closing or opening the web browser, or even when the web cookies were ex-paired On the other hand, for back-end, that was a bit different because you need to have a concept of a user life cycle, but they did have a request, so then that is what you used For us, a request was a session, and that we had our common abstraction of the session that we could communicate around The second thing we learned was about learning and sharing, and growing together before there are many differences between web, machine learning, back-end, mobile, and that affects the way we work at engineers, and at Spotify, the back-end is played out in thousands of microservices

Our mobile apps, they share huge monorepos, and more than 100 developers working on the same monorepo Also, back in microservices at Spotify, we can deploy them worldwide in a matter of seconds, and our mobile apps we've then released in a weekly cadence >> And these are constraints that we need to take into consideration when building out our software, and while we found the abstraction that is we came up with very helpful to allow us to communicate across our platform boundaries, also taking the time to really learn how we work differently, based on our different backgrounds, also proved very, very useful For instance, one of the main problems that we had with the old ABA system was that feature flags weren't reusable, and that was fine for web and back-end because they had control over how they deployed, and who were using what version of their software On mobile, if you messed up setting up a feature flag, that would delay the experiments by weeks, because you would have to wait for a new mobile release, and then people to actually start using that release

So, we learned from that, and then, in the new system, we made sure that properties on the web were reusable so that we wouldn't face this problem again But then, we also knew that we wouldn't add that complexity to back-end and web, because they didn't really need it And last thing was that by finding these common abstractions, and growing, and learning, and really learning to trust each other within those teams, we could really utilise our shared expertise and build a great product Compared to the old ABA system, our new experimentation platform has really clear separation of concerns, we have idiomatic solutions for things like remote configuration, experimentation analysis, for data collection, et cetera And we know all of these things because we've managed to answer all of those, "Arcs, if they only had talked to each other, problems that arose with the early ABA system

" >> However, this wasn't all unicorns and magic feeds It – setting up the teams got – was really a hard work for us And it took us much longer than expected to release that platform The first problem we had was to ship that in a matter of months, but actually it took closer to one year It took time to learn and like the specifics of each platform, and how they are different from each other

It also took us some time to understand that the developers were thinking about the same problems, but on different ways, because they have different perspectives It was only after all of this time together that we really felt comfortable to make compromises and trade-offs between disciplines It took strong technical leadership and guidance to make it through comfortably, and to trust each other, and also to trust the product that we were building together >> Also, the truth is, having cross disciplinary teams doesn't work for everything Infrastructure in particular is one of those things where you're dealing with problems that only face back-end developers, or only face web developers

Both me and Raul work on mobile infrastructure teams and only solving problems for mobile developers, but one of the things that we took back from this experience and this other team we worked on, that it wasn't really the power of the cross-disciplinary team that allowed us to be successful, it was the fact that we had a diverse set of perspectives on the same problem that we were facing, and that we were solving more of the problem for more people And the practices that we've talked about, having common abstractions, whiteboarding and visualisation, that allowed us to understand each other, and talk in a language that we all understood Learning and growing together meant that we felt safe to share our different idea, knowing that we would listen to each other and incorporate all of the learning into our new platform So, really this wasn't actually a story about how cross disciplinary team in particular bit a great product, but how we had a diverse team, and allowing that diverse team and those diverse perspectives to really impact the product that we were building made us build great software together Thank you!

Source: Youtube

This div height required for enabling the sticky sidebar