Scaling With Ease on Mobile

At Chegg, we have been rapidly developing products such as Math Solver, Chegg Prep, and our infamous Chegg Study service to better serve our students.

However, with the excitement of rapid growth comes challenges in regards to how to work most effectively as a team. I want to share my experience as to what strategies were most effective for our team on a time crunch, as well as what steps we took to better scale as an organization with legacy code.

When starting to scale, the team does not always initially make the right decisions. Usually, we find ourselves with monoliths or very coupled code (ie. mono-repo for multiple apps). However, what’s important is that the team is constantly evolving to find new solutions to increase our efficiency.

This is what leads us to break our code base into more controllable and smaller frameworks (app and shared components), bringing more value and high standards to the team. I like to call them “self contained frameworks” 💪.

You may be wondering, what does a self contained framework consist of?

• It avoids unnecessary dependencies.
• It has as many unit tests as possible.
• It contains an example app that explains how others should integrate your code.
• It has proper documentation, both verbal and technical (jazzy can be very helpful here for iOS).
• It is treated like every third party framework for users of given framework (the app teams).

Every point here is optional, as you need to find the right balance for every framework. Every framework is different and has its own usage, so find the formula that works best for each one.

Furthermore, when multiple teams are working together, synchronization is a must. It is important that other developers on your team understand the “why”, so they can continue your work effortlessly and with the same standards (maybe even better 😎). Part of being on a team means that everyone needs to be on board and understand the motivation.

Like any other engineering endeavor, start small and work up gradually. On my team, we considered ideas for new frameworks that would allow us to focus a lot more on how a framework should behave in our eco-system (documentation, CI, tests infrastructure, ease of extension, etc.) and a lot less on complexities of the framework’s contents. We decided the following frameworks will serve the most value in the shortest amount of time:

1. UI components framework — this is a similar idea to UIKit, which provides all of the necessary UI components developers will need (Buttons, Labels etc.). These components should be based on the company’s style guide and should include all the colors, fonts etc. (in general, this should be everything you need relating to UI.
2. Utilities framework — this will include extensions and utility models that will help you save time in your day to day.

For both these frameworks and future ones, try and make sure that they are self contained and decoupled as much as you can from your code and can be easily integrated with all of your apps. Many places usually have these frameworks in some sort of structure. However, from what I saw, the frameworks are often not decoupled from everything else, which prevents us from scaling.

The next steps were to share the idea with the team, take ideas for improvement, and create a plan with small milestones.

Here was our plan:

1. Create a tech design of how we are going to both implement this and share it with the team for feedback and fine tuning.
2. Implement + Unit-tests according to tech design.
3. Create an example app if needed. For UI components framework, this is a must!
4. Write up documentation. We wrote verbal with markdown and technical using jazzy for iOS. Documentation also included steps to work with the example app, how to release new versions, and how to create pull requests.
5. CI. This step is still a work in progress, but the idea here is to have a full pipeline with the needed script to be able to automate the release process for these frameworks. Many of the things we will need for one framework will be needed for others, so this is very important!

UI Components Framework

This area can give amazing value and order. It should be defined according to the company style guide and handled closely with one of the designers.

Some of the benefits:

• It will eliminate UX/UI bugs (or a very small amount) and easily fixed on the platform developed by releasing a new version.
• It’ll be much easier for new hires when building new features with UI.
• Less time can be consumed on review with designers.
• It is a single place for developers to look for style guide components.
• It will helps reduce human errors by using components and colors from a predefined set.
• Moving to a new style guide is very easy — just make sure that you build your framework correctly from the start to support future style guides.
  On another article, I will provide a more hands-on approach (WIP 🚧)

The development of this framework can and should happen in stages. First, tend to the most basic components such as labels and buttons. Afterward, choose components according to impact. This gives a more gradual development with small milestones that won’t disturb ongoing work too much.

Utilities Framework

This framework is easy to start, as it is ongoing work from all of the developers on the team.

The main idea here is to maintain a shared place for all utilities used in the project emphasizing documentation (this is very important, otherwise it will just be an unused pile of code). This is very valuable to large teams, as fewer components and extensions will be created multiple times within different projects. In addition, it can really help new hires to onboard the project and to know what’s available.

Examples for good extensions:

• JSON helper methods.
• String manipulation syntactic sugar.
• FileManager helps.

Architecting our App Frameworks

We now have shared frameworks to be used by our teams, so how should we build our app architecture to accompany these frameworks nicely?

For one of our apps, which has a product requirement of sharing some of its components to our other apps, we have decided to do the following:

Relationships Diagram between frameworks and apps

Okay, what’s next?

You may be asking yourself: what do I do now? The answer is simple: try and separate your code into small modules with documentation and decoupled from others. Think as if you were developing your components to someone from the outside. This will result in great generic decoupled components.

You might be thinking: “Is it worth it? This can prolong development!” From my experience, you quickly see a positive impact, and always have the option to change things in the future. If you are seeing much longer development times, consider doing less abstraction. Make sure to decide on what is right for your team, as there is no one correct answer.

For example, let’s take a simple notes app. We can create a main framework as the root of our app that will coordinate everything. Next, we can create a components framework for taking notes, scanning docs, and more. Last but not least, a shared framework can be made to sync shared code between all frameworks. This is a simple yet powerful way of building your app, allowing the components to be used by other apps in the future.

Conclusions

Having self-contained frameworks with the guidelines that I mentioned can really give great value and guidelines to people in large teams. From personal experience, if you don’t have a UI components framework or a utilities framework, you should consider them as the first candidates, as they make an amazing impact in the least amount of time.

As small warning, do not make these frameworks your junkyard and put everything inside. Take your time to consider what should and shouldn’t be there and make sure you pass this understanding to others so the rules and guidelines are always maintained.

I hope that this will help and that you enjoyed reading this! If some of you have any feedback or questions please feel free to comment or contact me :)