Server vs mobile development: Where the code runs matter

When the code runs on your servers, you have much more control over the “context” in which it runs. On the mobile devices, the device OS and the user control the context. This difference leads to some subtle implications.

One significant set of differences comes from the lack of control of the platform. For server-side code, one can choose from a wide array of languages. For the mobile code, however, the best choice would almost always be the one dictated by the platform – Java/Kotlin on Android and  Objective-C/Swift on iOS. Further, for the server-side where one can stick to a particular version of the language. In the case of mobile, the platform controls the language version. Same goes regarding the hardware choices – one can choose to use different types of server machines specialized in handling those jobs, eg. GPUs for math-intensive computes. While for the mobile-code, one had to write a good enough fallback to support a wide-enough set the devices. Similarly, the server-side has to rarely worry about the server killing a running process while it is normal for mobile OSes to kill backgrounded processes eventually.

The other set of differences comes from the temporary changes to the platform introduced by the carrier and the user. A network request running on mobile has to be robust enough to deal with intermittent broken connectivity to outright unavailability of a data connection, e.g., due to the user switching to the airplane mode. On mobile, network type matters as well. A network request on cellular would usually cost more than a network request on Wi-Fi to the user and a network request on roaming even more. On mobile, the code has to be aware of not doing unnecessary work when the user is low on battery. Server-side code is rarely subjected to such constraints.

Lastly, it is possible to parallelize and speed up the server-side code by adding more resources like RAM or better CPUs. If a certain number of servers are not enough, you can add more. There isn’t usually a way to offload compute-intensive or memory-intensive work off of the mobile devices without trading it off for network latency and sometimes, user’s privacy as well. While it might be preferable to go with a multi-processing approach in the server code to avoid concurrency issues, on the mobile, however, multi-threading being more straightforward and less resource-intensive is almost always the choice.

Apple vs Google: Naming of flagship Android vs iPhone

iPhone

  1. iPhone
  2. iPhone 3G -> iPhone 3GS
  3. iPhone 4 -> iPhone 4S
  4. iPhone 5 -> iPhone 5S
  5. iPhone 6 -> iPhone 6S (and plus sizes)
  6. iPhone 7 (and plus sizes)

Android

  1. Nexus One
  2. Nexus S
  3. Galaxy Nexus
  4. Nexus 4
  5. Nexus 5
  6. Nexus 6
  7. Nexus 5X & Nexus 6P
  8. Pixel & Pixel XL

While iPhone is recognized as a global name while erstwhile Nexus and now, Pixel has almost no branding outside of the Android fanboys.

Further on Google’s naming snafu:

  1. Nexus 7, Nexus 10, and Nexus 9 are tablets. 7 & 10 were launched with 4 and 9 was launched later.
  2. Pixel brand was originally used for Chromebook Pixel.
  3. Nexus 5X and Nexus 6P were new versions of Nexus 5 and Nexus 6, respectively. It seems like the two teams couldn’t agree on a single suffix letter.

The Internet and the City Advantage

Cities have been central to the human civilization. Their dense population provides a platform for the serendipitous interactions and cross-pollination of ideas from different domains, their abandoned portions provide cost-effective real estate to struggling artists and entrepreneurs, their riches provides jobs, sometimes, side-jobs for the innovators to experiment. No wonder innovation in a city grows super-linearly (~(size)4/3) with its size.

But the Internet was supposed to destroy all advantages a city has over the rural areas. The Internet was supposed to convert all of us into a global community. It did. But the cities have emerged even stronger, everywhere. One way to rationalize this is to realize that the Internet provided a platform to the cities a rent seeking ability which was extremely limited in the pre-Internet era. When a family in Kansas books an Airbnb in Thailand using Mastercard credit card, books the flight with Expedia, and uses an Uber in Thailand then these intermediaries take a cut. Similarly, when a person in Nebraska buys West Texas Intermediate from New York stock exchange, then New York stock exchange takes a cut. Now, what happens when these companies take these cuts? A big chunk of that is used for salaries, expenses,  or charity donations which usually are highly localized activities and benefit the cities where these companies are headquartered. Most of these rent-seeking activities were either non-existent or of limited leverage in the pre-Internet era.

Note:

  1. The first paragraph of this blog post is heavily inspired by “Where good ideas come from” book.
  2. The city term I am using is akin to an urban area. In the US, a suburb is seen as a separate entity, which I am treating as a city in this parlance.

Consumer Internet: why audio can’t be as big as text, photos, and videos

Bandwidth of different senses

The bandwidth of different senses

 

Our brain loves distractions, and multi-tasking gets bored quickly. When we read text or watch a photo, it engages us visually, a video (with audio) engages us even more. The bandwidth of eyes is much larger than the bandwidth of our ears. When we are watching something, it utilizes more bandwidth and hence occupies more of our attention span. Also, given the way our eyes work, we can focus more on the exciting aspect of the visual feed. Compared to that, audio underutilizes our brain’s bandwidth. Further, the unidimensional flow of audio data at a linear speed does not mimic our ability to process it. Contrast forced direct listening with how non-linearly humans read.

How eyes jump forward and backward while reading

How eyes jump forward and backward while reading

And that’s why video games are even more engaging than video. They utilize the bandwidth even further by forcing us to think and act in the game.

Since audio underutilizes our brain’s bandwidth, it leaves spare bandwidth for distractions, including eating food, driving, and exercising. No wonder most audio consumption is passive and happens as a secondary activity as opposed to being a mainstream activity like reading or watching movies.

90% vs 99%

Consider two systems, the first one is 90% reliable and the second one is 99%. The wrong to compare them is to compare the reliability and conclude that the second one is 9% (or 10% if you take 90% as the base) better. The right way to compare them is to compare the unreliability and conclude that the first system fails in 10% of the cases while the second one fails only in 1% and hence, is 10X more error-prone than the second. The reliability comparison is a vanity matrix while the unreliability comparison not only demonstrates the user perception (“The user saw then crashes in past one hour” vs “The user saw one crash in past one hour”) drastically but also shows the effort that goes into making the system more reliable.

Note: While I am taking reliability as an example of the metrics, the argument can be made for similar metrics.

When aggregation works and when it doesn’t

All consumer internet products are either about consumption, production or both. A blog site is primarily about consumption. A photo transforming app is primarily about production. Social networks are consumption heavy. Good Messaging apps are symmetric. And a grievance collection product like BBB is production heavy.

Building aggregation on top of similar products is a well-known strategy.  The hard realization to note is that it can succeed only in very specific scenarios. Look at all the successful aggregation products, travel booking sites, news aggregators, RSS readers, discount coupon aggregators. As opposed to that, attempts to write an email aggregator, a social media aggregator etc. have not been as successful. And that’s the underlying theme, aggregator works well for consumption only interfaces where the product is sourced from many sources (more the better) and  is standardized in the eyes of the consumer. They have limited success almost everywhere else. And this just doesn’t apply to software products. Microsoft tried and failed to have their own hardware stores since their offerings were similar and a subset of BestBuy whereas Apple succeeded in the same strategy despite the naysayers.

The Android-Chrome merger saga

Articles with the following titles would be considered a joke
 
1. “BMW is planning to merge its series i5 cars and Motorrad bikes”
2. “P&G is planning to merge tissue paper and toilet paper”
3. “Arm and Hammer is working on merging face wash, body soap, shampoo, laundry detergent, and dish cleaner”
 
Not that these combinations can’t be made or have never been made but consumers would just not buy them. They are usually inferior or more convoluted, or even worse, both.
But the Android-Chrome OS merger stories keep popping up every few months. Excluding the technical jargon, it’s as much of hogwash as the first three. In the longer run, markets specialize and not generalize.
Note: The only time when generalization appears to wins is when an entirely new market is created which renders multiple existing markets customer-less. And that too is a head fake in favor of generalization.

Startup valuations

In 2001, Amazon’s share price crashed from 100$ to 6$, they had to do a 15% layoff. But it was Jeff Bezos’s perseverance, tenacity and grit because of which Amazon survived. As several startups from the Bay area to Bangalore get a mark-down of their valuations, the question about how many will survive and eventually produce a [positive] return for their investors is being asked. Between what a startup’s real value is and how viable is its business model, the real question to ask is how committed are the founder(s) to make things works. In the longer run, only that will matter.

Voice Interfaces: The Missing User Interaction Element

Amazon Echo

Amazon Echo

Apple Siri, Google Now, Amazon Echo, and Microsoft Cortana have garnered a lot of press lately. But one thing which is still missing out is voice-native user experience.

Let me illustrate that with the evolution of user experience on touchscreens. When they first came out, there was a stylus, and that’s it. It was an inferior version of the mouse-keyboard-monitor trio. Then some fantastic interactions were invented. Interactions like double tap to zoom, multi-finger rotation, swipe to like/dislike, pull down to refresh, long-press for options, and a Swype keyboard. All of these were native to a touchscreen-based environment. Porting them back to a mouse-keyboard-monitor trio was of limited utility at based and useless at worst.

Read More

File size should always be of “long” type

int getTextFileSize(String fileName) {
  return (int) (new File(BASE_DIR, fileName).length();  // WRONG
}

A 32-bit signed int can deal with ~2GB worth of data. And if your code is not going to deal with files larger than 2GB, why worry? But what if  someone wants to use the same code for a video file some day? Or What if someone writes another code to iterate over all the files in the BASE_DIR directory? Most likely they will be inclined to use int for the final sum as well. Adding integers in most languages results in int and automatic overflows into a negative number (and even worse, back to a positive number). The caller code might think that BASE_DIR does not exist. Therefore, the best future-proofing is to never have file size stored as an integer. Even, Android platform got it wrong with StatFs#getBlockSize and corrected it by adding StatFs#getBlockSizeLong.