Some time ago I wrote about the error of slavishly following “best practice” without asking why. And I was reminded of this again the other day when a friend forwarded me a blog post by . in the Dropbox tech team
The post explains that the team used to try to share as much code as possible between its iOS and Android mobile apps, but this became increasingly costly and they have now moved away from it. At first glance code sharing seems an entirely sensible thing to do—less work, more consistency—but, as the article explains, there were many hidden costs for Dropox with trying to make one piece of (shared) code usable and relevant to two platforms.
It’s an excellent piece of writing for many reasons, but (for me) most of all it’s quite specific (so the reader can get a feel for the challenges the team faced) and it’s very candid—unusually so for a corporate blog post. Eyal is honest about hiring difficulties, that people sometimes leave the company, and what the consequences are of these things.
And, of course, it also carries an important lesson. The idea of using platform-independent code for writing mobile applications is often called “best practice”, or maybe just downright sensible. It’s very easy to be seduced by the hype. “React Native is from Facebook—it must be good”, “Google is promoting Flutter—we should use that.” People don’t literally say that, but when the technology advocated is the next shiny thing it’s often hard not to see that below the surface.
talks about having to jump through hoops to get their software working, and sometimes having to create their own hoops in the process. Fortunately, they’ve now been able to move to a much more efficient way of doing things.
But this is their story. It would be as wrong to use one story as the reason for us to go down one route as it would be to use claims of best practice to go down another route. In the end we have to listen to the evidence, think about our own context, make judgements about our future, and make our decisions ourselves.