Dropbox: Rewriting the heart of our sync engine

Once you have a successful product at your hand; things start to get complex. It's not that the world has got complex problems; adding features and at times making this simple add complexity.

Sujay Jaykar for Dropbox:

Shipping any change to sync behavior required an arduous rollout, and we'd still find complex inconsistencies in production. The team would have to drop everything, diagnose the issue, fix it, and then spend time getting their apps back into a good state. Even though we had a strong team of experts, onboarding new engineers to the system took years. Finally, we poured time into incremental performance wins but failed to appreciably scale the total number of files the sync engine could manage.

Once you have a successful product at your hand; things start to get complex. It's not that the world has got complex problems; adding features and at times making this simple add complexity. Also, in today world, technology is so ingrained that anything you build should have the ability to scale almost instantly. But predicting how much to scale is hard. At a given point in time you do have to make a decision to build something again. The approach that you take makes or breaks your new shiny product.

I loved Dropbox's approach here. They created a "rewrite" checklist.
I understand that one needs to refactor, optimize constantly. But at a certain time and due to resource constraints, this stops happening.

Can you deliver incremental value?

A PM is typically delivering value to their customers every release. I feel this is a very important checklist item; rewrites are slow and the teams needs to come together to pull this off.

They followed this up with a "can you pull off a rewrite" checklist

It's much easier to write new code than fully understand existing code. So, before embarking on a rewrite, you must deeply understand and respect the “Classic” system.

This comes back to bite you hard. This I feel is the single most important item for a developer and a PM to understand how your existing product works.

Do you have the domain experts who understand the current system?

This is important. If you don't have some; hire a contractor.

I have been involved in a couple of rewrites myself and things did not go as planned. This checklist made me realized how easy it would have been for me to apply this to every single aspect of the product and then move forward.

Subscribe to Optimistically Skeptical

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe