LinLog

A few months ago, the DropBox blog had an interesting article on code sharing in their mobile apps.  It was a good reminder that developers should be mindful of not fetishizing code re-use.  Like so many things in engineering, re-use is generally good, but still involves trade-offs.

The short-short version of the article is that DropBox originally had the idea to share code between their iOS and Android mobile applications.  After all, why write the same app twice when you can do it once?  Well, it turned out to be a really bad idea.  Because they were doing things for both platforms in a custom, non-standard way, they ended up taking on a lot of extra work just for the sake of re-using the code.  And not just in the amount of extra code they had to write in terms of custom libraries and tools - there's the extra effort of bringing new developers up to speed.  In fact, they eventually realized that it would actually be less work to just write everything twice and ended up abandoning their code-sharing approach.

Of course, this is an extreme case.  Trying to share code between two radically different platforms with different native implementation languages is bound to generate some issues.  A more prosaic example is the left-pad debacle.  You know, the one where a developer removed an 11-line JavaScript "library" from NPM and broke half the internet's deployment scripts.  But in that case, the scale was reversed - instead of trying to share a significant amount of code between a couple of projects, the left-pad package shared a completely trivial amount of code between an absurdly huge number of packages.  But the underlying problem is similar.  By trying to share that 11 lines of JavaScript "the right way", you end up taking on an external dependency that now has to be managed and probably generates more long-term maintenance effort than you saved from not writing the code yourself.  (I mean, seriously, why use a library for something that any half-competent programmer could write in less than 15 minutes?)

On the same theme, I've seen similar problems in client-side JavaScript.  I've worked on a codebase or two where large portions of the front-end were essentially cobbled together out of jQuery plugins that sorta-kinda work together, but not really.  Clearly the intention was to save effort by re-using existing components, but it didn't quite work out.  Sometimes it was because they didn't play well together, other times it was just that one of the components was not very well written.  In a couple of cases, after examining the plugins and the desired behavior, it became apparent that I could just write a version that did work cleanly in an hour or so - less time than it would take to debug the third-party plugin.

Of course, that's not to say that re-using code, whether your own or someone else's, is a bad idea.  It's clearly not.  Sometimes you find yourself writing nearly identical components for multiple projects, in which case it probably makes sense to abstract that into a shared library.  Or maybe there's a third-party library that already does more or less exactly what you need, in which case it probably makes sense to just use it.  That's all fine.

My point is just that "re-use some existing code," like any other idea in engineering, comes with trade-offs.  Sometimes those trade-offs are minor, such as the cost of managing a dependency that buys you a really big chunk of functionality.  Other times, they're pretty major, like the opportunity cost to DropBox of breaking all of the standard platform tooling.  Either way, the important thing is to think about those trade-offs and evaluate them honestly, not just jump to an "easy" answer.