Issues could easily take several days until their root causes were uncovered and fixed, so each major version of Dropbox spent weeks in each stage.

You want to get quick validation on the functionality and utility of the feature.

Each individual change you make might be relatively simple, like a tweak to the CSS changing the size of a font, or more substantial, like enabling the Badge on a new file type.

You could set up user studies, but these are relatively expensive and slow, and are a statistically small sample size.

Ideally, you write some code, add it to the codebase, have it tested automatically, and then release it immediately to some users so you can gather feedback and iterate.

Every code change and every new version requires you or someone on your team to do a piece of work.

You need to make sure that any random commit doesnt break the development environment for everyone, that the machines that compile code are up and running, and that mysterious bugs are found and routed to the correct engineer to fix before a new version is released to the world.

For the Dropbox Desktop Client, this also means keeping up lightning-fast sync rates, making sure core workflows (like sign-in) still function, and minimizing crashes.

Dropbox Client Problems Manual Operations Work

Ideally, you want to minimize manual operations work, and you want product quality to be high.

The product engineer wants to release as quickly as possible, with ambitious new ideas.

The platform engineer doesnt want to stay until 10pm everyday to make that happen, or to have to constantly say no to the product engineer because changes are too risky to product quality.

The experience was unpredictable for engineers, because there were frequent rollbacks and delays, and it took a lot of time to figure out and fix the source of new bugs and test failures.

It would take up to 3 days before a product engineers code reached an internal user and 10-18 weeks before it was fully released.

Most of the release process is handled by a Technical Project Manager with two engineers who assist part-time, and debugging work is quickly routed to the responsible team.

Code is sent to internal users within one business day, and to everyone within 2-4 weeks.

It took 10-18 weeks from when code was added to the main branch of the codebase until the feature was deployed to 100 of Desktop Client users.

Dropbox Client Problems Update Is A

To quote from old documentation, the long cycle time is to ensure that we are not putting insecure or very broken code on our users machines, because auto-update is a slow and imperfect process.

Push to the build machines, which would make new official Dropbox binaries.

This meant writing up an internal email with the commit log, and if the build was going to be posted to Dropbox Forums, a forum post.

If there was a sufficiently big issue, set the configuration back to a known good build.

Do steps 1 - 4 again to make a new build with the desired fix.

The Sync On-Call and Primary On-Call together would do an initial investigation to either solve the problem or assign it to a person who would.

There were three versions of Dropbox being served at any given point of time: the office build, which was just for internal users; forums build, which external users could beta-test; and stable, the version currently given to the world.

Keeping track of all three was assumed to take up both On-Calls entire weeks, but was more difficult for newer engineers without as much context.

Dropbox Client For Mac Problems