Custom Modularity

28 April 2014

Does one size fits all,
when all users are the same,
but claim uniqueness?

Google's Project Ara has been in the news a lot in the last couple of weeks, proposing to give consumers the option of upgrading and modifying their phones on the fly and for reasonable cost. It seems that hardware is finally catching up to the modular framework design that has long since dominated software. Google's hardly alone, as even a company like Razer can attest. However, I'm not yet convinced that hardware's quite ready to adopt this particular software paradigm so strongly.

Ara's tech is definitely novel and certainly may disrupt the current phone hardware landscape. The ability to swap out modules will produce phones with combinatorial capabilities not achievable with current phones. A photographer may have a high-end camera module that can attach to traditional lenses. An engineer may have phones with a built-in multimeter or other useful tools. A mad genius may have a custom module to control his army of evil robots. Yada yada, etc etc.

That said, Ara will only be as good as the sum of its parts, and it remains to be seen whether other hardware manufacturers will step up to the plate. It's not like we didn't have interchangeable parts of standard interfaces before. Google's just made that interface layer available for consumers to modify and OEMs to adopt. Ara almost feels more like an experiment in hardware UI than anything else. Up until now, (imo) there has been two main ways to hardware development: either find the sweet spot between available economies of scale in new components and consumer demand, or sacrifice those economies of scale for a higher-grade, luxury item with a smaller market niche. Either way, no hardware manufacturer has all that much ability to offer more than a handful of options with each release.

Really, traditional hardware development is almost like making a singleton class, but with really consistent coding standards. In software, it makes perfect sense to adopt modularity. It allows for multiple authors to write different components independently. However, even in that scenario, operational efficiency is traded for ease of modification. There undoubtedly comes a point where the bloat of the overhead required to satisfy modularity constraints becomes too unwieldy to remain sustainable. In my view, the issue with modularity is that each component must be design to accommodate more than the bare essentials. In theory, that doesn't seem like such a big deal, until you come across a scenario in practice where you only want the bare essentials.

Minimalism (I would hope) is more than just a trendy term designers like to throw around. My view is that when it comes to hardware, the consumer wants either a machine that does A,B, and C or a machine that does X,Y, and Z, not necessarily a machine that is capable of doing any size-3 subset of A-Z. I suppose whether or not the module market emerges will determine if the additional hardware complexity needed by Project Ara to make modularity possible is worth it. Can't help but admire Google for stirring the pot and trying to make some waves in a stale technology space, but all waves (especially Google's, huehuehue) eventually subside, and sometimes the after is indistinguishable from the before.

(As an aside, semi-permanent magnets are pretty freaking awesome, but I wonder why they're necessary when you could just as easily have an electromagnet that's only active to negate the passive magnetism between the phone skeleton and the modules)