Parallelizing A Feature Across The Team

Recently Peloton introduced a new feature called Programs and Collections. Peloton Programs are curated training plans that take the guesswork out of your training by creating a week-by-week schedule of workouts that incorporate expert instructor insight to help you reach a clearly-defined goal. Collections are classes grouped in our library by a specific theme, like special events, singalong rides, and more. We started off with three programs and nine Collections for our Bike, with plans to add more over time.

Programs and Collections was a huge cross-team effort. This feature is one of the best examples of how our Android Team parallelized work across 4 team members. The final product looks something like this:

Programs and Collections

How we divided the feature

The feature has two screens. The first screen shows all the programs and collections’ thumbnails, while the second shows the details of a selected program/collection. We broke this down into four sections, and each team member was given the responsibility of one of these components:

  1. List thumbnails — responsible for the program/collection thumbnail and all the metadata associated with it.
  2. Detail content — responsible for showing class thumbnails associated with a selected program or collection including scrolling behavior.
  3. Detail header — responsible for showing all the metadata associated with a selected program/collection and fading effect on scroll.
  4. Browse and navigation — responsible for overarching navigation and integration into the current product.

Considering the entire feature these four seemed to be logical choices for smaller components because developers could work on their part without any overlap.

How this helped us

Using the divide and conquer approach helped us to keep the development process smooth and stress-free for developers. Some of the specific benefits we saw were:

  • Faster development: The way we divided the screens into chunks made it easy for a developer to work independently. Thanks to the architecture we follow at Peloton there were very few occasions on which we needed to deal with merge conflicts.
  • Focused development: Developers were able to deliver optimized code for each component.
  • Fewer bugs: Keeping sections smaller made it easy for developers to write clean code, write thoughtful tests, and make sure that their component worked as expected. The end result of combining all these small chunks gave an almost bug-free final feature.
  • Small feedback loop: Each part represents a portion on the screen so it was easy for the product team to UAT it and provide feedback, instead of waiting for the entire feature to be completed.

Case Study: How focused development helped in delivering rock solid feature

The end result looks great, but we also made sure that the user experience and app performance are both great too. When it comes to performance improvements developers often neglect to invest time in reducing Overdraw. As the name suggests Overdraw is the number of times a pixel on the screen is redrawn. Fortunately, you could easily check if your app is redrawing pixels on the screen by enabling Show overdraw areas in Developer options; the official docs give various ways to reduce the number of Overdraws and using this we reduced the number of overdraw on our screens.

For the small number of list items we have now, this doesn’t make a noticeable difference for the end user. However, in the future when we have more list items, performance tweaks like this will help us make the scrolling and overall end-user experience great. Below are some of the before and after screenshots showing the overdraws reduced.

Before fixing the overdraw
After fixing the overdraw

Communication is the key

We take pride in our team’s communication. When working on independent chunks that contribute to a bigger feature, it is important to communicate the changes. We often schedule quick chats to discuss the approach on something, which helps keep everyone on the same page, gives consistency to the code, and makes sure there were no surprises in pull requests, ultimately making a review of pull requests quick.

Case Study: How communication made it easy to overcome a technical challenge

Apart from occasional merge conflicts we never really had any major problems related to development. However, there was one technical challenge worth mentioning. The programs details screen required the section details to snap to the top upon clicking a section tab. However, RecyclerViews’ default behavior doesn’t allow this. Everyone had some suggestions, so we had a quick team chat to narrow down to one or two approaches. When the PR was finally created for this task, everyone on the team understood the approach we chose and was on the same page. Below are the screenshots for before and after the changes:

Default scrolling behavior
Expected behavior

This is just one of the examples of how we parallelize work at Peloton. The divide and conquer approach helps in tackling big features, while we prepare for the fact that the implementation will be different for every feature. Regardless of the size of your team, this approach can help build a robust feature.