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. When the code runs on the mobile devices, the context is controlled by the device OS manufacturer as well as the user. This difference leads to some subtle implications.

One major set of differences come 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. Also, unlike server-side where one can stick to a particular version of the language; in the case of mobile, the language version again is controlled by the platform. 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 of the devices. Similarly, 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 come 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 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 cognizant 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 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.

Book summary: The Lean Startup by Eric Ries

book_cover_the_lean_startup

The book consists of the learnings which the author had while working on his startup IMVU. The book focuses on the concept of validated learning and the build-measure-learn feedback loop. It tries to bring in a systematic approach to measuring the progress at a startup. A startup has a true north, its vision. It employs a strategy that includes a business model, a product road map, and a view of partners, competitors, and customers. The product is the result of the strategy. Products constantly change (engine tuning). Strategy changes occasionally (pivot). Vision rarely changes. In general management, failure to deliver results is caused by failure to plan or failure to execute. Both are frowned upon. But in the modern economy, both are useful tools for testing new ideas.

Vision

A startup is a human institution designed to create a new product or a service under conditions of extreme uncertainty. Success under such scenarios requires rapid experimentation.

Learning

There is a lot of learning involved in the process, and sometimes, when things go south, people resort to saying, “I learned a lot”. What’s more important is to figure out validated learning. The goal is to cut down to the absolute minimum effort required to learn what customers want and eliminate everything else. Eric Ries wrote 3-D avatars as IM add-ons for popular IMs in 2004. During the user testing phase, he realized that not only do users not understand what an add-on is, they also don’t mind installing a new IM software. A lot of heavy IM integration turned out to be a waste of effort. After this, Eric and his team launched several experiments regularly to test what works and what doesn’t.

Another counter-intuitive thing that IMVU experimented with is charging early. Many startups delay charging their customers. Not having any revenue is better than having low revenue since the former invites the imagination of overnight success once they start charging. The downside is that it can lead to the creation of a product no one is willing to pay. Conclusion: start with a low-quality prototype, charge customers from day one, and use low-volume revenue targets for accountability.

Experiment

Nick Swinmurn had a hypothesis that people will buy shoes online. Rather than purchasing inventory upfront, he took photos of shoes at local shoe stores, and if the users bought it, he would buy and ship it to them. This minimum product tested customer demand as well as many other business issues like payments, returns, and customer interaction. Amazon acquired Zappos acquired for $1.2 Billion.

  1. An experiment starts with a hypothesis. A value hypothesis tests whether the product/service will deliver the value to its users. A growth hypothesis tests whether new customers will be able to discover the service.
  2. To test the value hypothesis, find some customers to experiment. Don’t go for an average customer but find an early adopter, whose needs are most accurately served by the product.
  3. Now, build a concierge minimum viable product. Such early adopters are more forgiving of the quality of the product, and their feedback is useful to know whether the product fulfilled their needs or not. If users complain about a missing feature and they’re on the roadmap, that’s a good thing, since it implies that the team understands their customer. If there is a feature that is on the roadmap, but the user does not complain about it being missing, then that’s an indication to remove that feature.
  4. The results will guide you to validate the hypothesis.

Steer

The Build-measure-learn feedback loop is at the core of the Lean Startup model. After building the MVP, the goal is to rapidly learn and iterate upon the product based on the user’s feedback.

Leap

All startups make some assumptions (leap of faith) about their viability. In the case of iPod, there were two assumptions, users would put earphones in a public place (“analogous to Walkman”), and they would pay for the music (“antilogous to Napster”).  Only the second one was a leap of faith. Verifying these assumptions is paramount. Toyota does it via Genchi Gembutsu (“go and see for yourself”). Toyota’s minivan, Sienna’s chief engineer, drove through North America. He realized that kids are most appreciative of their environment and launched the new model with a particular focus on interior comfort for long trips. This lead to significant success for Toyota. Scott Cook, the founder of Intuit, believed that someday people would use a computer to pay bills and track expenses. He verified that the market for such a product by calling random people over the phone. One pitfall to avoid here is analysis paralysis. One can keep repeatedly talking to customers and whiteboarding over and over again. But many errors in such a strategy would go unnoticed since they depend on subtle interactions between the user and the product.

Test

Groupon started as a “collective activism platform”. That assumption failed. Andrew Mason experimented with a WordPress blog and a mailing list to sell discount coupons. They had no fancy forms on the site. The idea took off, and slowly every aspect of it was automated. It is essential to get early results with a buggy product then to perfect about based on assumptions that might not hold in the future. It is counter-intuitive for entrepreneurs who want to build a high-quality product.

Drew Houston had a hard time convincing investors about DropBox. VCs thought that the market is crowded, no one made money, and the problem was not an important one. Drew believed that all that was because all the current products were of low-quality. Rather than spending years doing thorough integrations, he made an excellent video demonstrating the seamless behavior.

Wizard of Oz is a useful testing process for such situations. Rather than building an automated system, fake it with a human. It is faster for learning what users want.

Sometimes, a user’s quality metrics are very different. Users care about how much they enjoy the product, not how much time was spent building it. IMVU had no time to build a smooth movement of avatars from one place to another. So, they decided to and were ashamed of, cheat by making avatar re-appear at the destination instantly. Users rated this teleportation among the top three most liked features. Therefore, it is of paramount importance to remove any feature, process, or effort which does not contribute to the learning you seek.

Some entrepreneurs fear the competition that MVP will bring in, usually, from large companies. Most of the time, the Product Managers at the big companies are overwhelmed by good ideas. If not, they can still copy the product at a later stage. And the fear of being out-executed remains.

Measure

After building an MVP and putting it out for the early adopters, test the riskiest assumptions first. Now define a baseline metric, a hypothesis to improve the metric, and a set of experiments targeted towards the same. Once you have the results, decide whether to pivot or persevere. One of the biggest dangers is to get stuck with vanity metrics like total registered users. They paint a rosy picture but does not tell you whether the product improvements are making it better for the user or not. AAA (actionable-accessible-auditable) metric would measure the impact of a particular feature.

Grockit followed the Kanban model, where there are four buckets – backlog -> in progress -> built -> validated. Each was containing at most three features. After validation, either they made the feature or discarded it.

Pivot or Persevere

A startup’s runway is the number of pivots it can make. Votizen started as a social network for verified voters to discuss civic actions.  That did not take off. Then it pivoted to @2gov, which allows users to recruit more verified voters for their petitions. This product has higher usage, but still, very few were willing to pay for it. They pivoted further to businesses as customers, who, despite signing the letter of intent, decide to eventually not buy the product. The final pivot was to use Google Adwords for acquiring users who want to pay to acquire more users. That worked out. Startup Visa Act was solely a result of that social lobbying.

Wealthfront pivoted from a virtual stock trading/gaming platform to an online service offering money management by professional money managers (ashishb’s note: and after the book was written, further to index-based investing).

Most entrepreneurs regret delaying the pivot. Vanity metrics, not having a clear success hypothesis, and being afraid of the failure, are the usual causes of delaying the pivot.

Types of pivots

  1. Zoom-in Pivot- A popular feature becomes the new product. Votizen moved from voter social network to a voter contact product.
  2. Zoom-out Pivot – The current product becomes a feature of the new product.
  3. Customer segment Pivot – The target customers change.
  4. Customer needs Pivot – where the customer base remains the same, but the product changes to suit them more. Potbelly Sandwich shop started as an antique store in 1977. It decided to sell sandwiches to bolster traffic. It eventually pivoted to become a sandwich shop.
  5. Platform Pivot – The product changes from a single-use product to a platform for the other products.
  6. Business Architecture Pivot – Geoffrey Moore observed that most companies follow either a high margin, low volume model; or a low margin, high volume product. Former is usually for B2B, and the latter is generally for B2C. A business architecture pivot is jumping from one to the other or vice-versa.
  7. Value Capture Pivot – where the way business makes money changes.
  8. The Growth engine Pivot – The business’ way of reaching new customers changes.
  9. Channel Pivot – The distribution channel for the product changes.
  10. Technology Pivot – The underlying technology to do task changes.

When pivoting to a strategy followed by a successful company, it is crucial to copy the essential and not just the superficial features.

Accelerate

Batch

It is counterintuitive, but smaller batches are much better for lean startups. They appear inefficient but allow faster turnaround for the product leading to a more rapid iterative cycle. It helps in earlier detection of a problem as well as quick feedback from the customers. Toyota used the small-batch approach to compete with its much more capitalized American counterparts whose batch sizes were relatively bigger.

Grow

New customers come from the actions of past customers. They inform others, end up showing the product to others, or end up purchasing the product again. Sabeer Bhatia grew Hotmail by adding a signature “Get your free e-mail at Hotmail” to every outgoing email. If you are asking whether your startup has achieved a product/market fit, then you are not there yet. When the product/market fit happens, it leaves no room for doubt.

Adapt

As a startup grows, it has to adapt to the changing customer base. Early adopters are more forgiving of the quality; later ones are not. Five whys help one to diagnose the problems and build the right set of things that should go into an employee training manual.

Innovate

Big companies can innovate, but for that to happen, they should secure resources for internal teams, provide an independent development authority, and the internal team should get a stake in the outcome. Toyota calls the manager in charge of running the development of a new vehicle, shusa (Chief Engineer). The parent organization must be protected to create this platform for experimentation. If the existing managers feel threatened, they will have an incentive to work against the new project. Also, if such a unit is kept hidden, it will attract more political battles since existing executives will be wondering what else could be hiding. Therefore, any team should complete ownership to run an experiment and see the end-to-end results. Every company has to deal with four types of works – launching a new product, scaling it for the broad adoption, combating its commoditization by incremental improvements,  and maintenance of the product in the long run as a part of the company’s product line. All the steps are essential, but the last stage of becoming the status quo is a hard one to swallow as an entrepreneur.

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

My rm -rf moment

Yes, it did happen, and no, I am not stupid enough to execute rm -rf *. It was a bit more convoluted than that. I was trying to prepare a customized SD card image for Android emulator. The fastest way to do that was to mount the SD card on my GNU/Linux machine and modify the files. The files on SD card have root as the owner. Therefore, the easiest way to maintain a clean state was to do all modifications using sudo. My script included a command rm -r ${base_dir}/${old_file}. While executing the script, due to an error both the variables were not set. It took me a few hours to recover; I never committed the broken script, so, I did not harm anyone else. But since then my bash scripts have always included set -o nounset.

Standardization

Standards exist so that products from different vendors can interoperate with each other, for example, sending email from Gmail to Yahoo! mail, and use common interfaces, for example, sockets for electrical appliances. The standardization does not always have to come from imposed standards; sometimes, it comes from the user expectations. For example, the interface of a Calander/Scheduling application is pretty standardized. There is little scope to differentiate a new Calendar application from the existing products like Outlook Calendar, Google Calendar, and iCal while just implementing the standard is still pretty hard.

One problem which standardization introduces for the product vendor is that there is little left to differentiate itself. For example, either the cables are compliant with USB-C standard, or they are not. The lack of differentiation produces perfect competition and hence, razor-thin margins. The model, thus, works only at scale. The same problem of standardization seems to have plagued products focused on email, calendar and RSS feeds. All three of them are pretty standardized. While one can provide a better UI like Sunrise does for Calendar, or over-the-top functionality like MixMax does, there is still relatively little scope for a product solving any of these to differentiate itself from others. Therefore, big companies with established distribution channels dominate.

The only exception to the rule is producing premium quality products, either in reality or perception and then wait for a niche market which will be willing to pay a premium hoping that they are getting the best product, for example, 41$ mini-USB cable and a 50$ MailMate email client.

Internet activists, the advent of snap judgement and Internet’s permanence

In 2013, we saw how internet activists’ snap judgements about interpretation (or misinterpretation?) of jokes at pycon destroyed the  professional career of two individuals (Source: A Dongle Joke That Spiraled Way Out Of Control).
The internet activism first sympathised with Adria Richards and then decided to side with the developer, eventually both of them (and SendGrid customers temporarily) took a major hit which could probably have been resolved offline and would have never become a part of permanent history.

As if this was not enough, this year the same story has been repeated with Gurubaksh Chahal and his girlfriend Juliet Kakish.
The claim goes that he allegedly hit his girlfriend 117 times and she allegedly suffered bruises and injuries, there is an alleged video of that proving the same (I haven’t been able to find one yet that does not imply it does not exist though) (Source: A Letter To The Board Members Of RadiumOne).

Read More

Thoughts on fixing tech recruiting

Enough articles have been written about engineering crunch in the valley while some solutions like increasing equity grants to engineers have been suggested, the bigger issue of the broken recruiting pipeline has not gained the attention it deserves. Its a job of recruiters to source potential candidates and most recruiters are compensated in form of a percentage (usually 20-30%) of the annual base salary of the hired individual.

Read More