How many source-code repositories should a startup have

Ashish on October 1, 2020

Recently, this question came up during the discussion. “How many source-code repositories should a startup have?”

There are two extreme answers, a single monorepo for all the code or repository for each library/microservice. Uber, for example, had 8000 git repositories with only 200 engineers!

I think both extremes are wrong. Too many repositories make it hard to find code and one single repository makes it harder to do simple things like testing, bisecting (to find buggy commit), deciding repository owners.

Here’s what I have seen works best.

  1. Backend code – ideally, one single repository.
  2. Frontend (web) code – one single repository. This can be separately tested and even outside contractors can access this. The web code is anyways shipped to the client, so, leaking it isn’t that big of a worry.
  3.  Mobile code – one repository per platform (Android, iOS, etc.) if there is no code dependency. Or one single repository if a common codebase like React Native or Flutter is being used. Again, those who access the mobile code won’t need access to the backend code. And given that this code in compiled form is sent to the users, there is less worry around leaking it.
  4. Open-source code – One repository per open-source package.

As opposed to a monorepo setup, this setup makes it harder to make simultaneous changes to backend and frontend, or backend and mobile apps. And that should be the right behavior anyways. Since backend services and frontend can be, or eventually will be, deployed independently of each other. Mobile apps are deployed independently anyways, so, the backend has to provide backward-incompatibility for that.

Celsius vs Fahrenheit

Ashish on October 1, 2020

The US is one of the few countries where the temperature measurements are in Fahrenheit. Elsewhere, Celsius is the norm. Usually, when traveling, I want an approximate mapping. Thankfully, it is linear and easy to memorize.

To convert temperature in ºC to ºF – double and add 30
To convert temperature in ºF to ºC – subtract 30 and half

Read More

I’m looking for financial partners and would like to connect…

Ashish on September 15, 2020

A sample of LinkedIn requests I receive these days.

Hi Ashish, I’m the CEO of [redacted]. [redacted]. I’m looking for financial partners and would like to connect to see if we’re a fit.

Hi Ashish, I’m the CEO of [redacted]. [redacted]. I’m looking for financial partners and would love to connect! – M

Hey Ashish, I’m the CEO of [redacted] – [redacted]. I’m looking for introductions to financial partners and would like to connect to see if we’re a fit. – S

Hi Ashish, I’m the CEO of [redacted]. [redacted]. I’m looking for introductions to financial partners and would love to connect! – K

Read More

Three days in Cancun (Mexico)

Ashish on September 5, 2020

Cancun, or, more precisely, Cancún, is a coastal tourist city on the Caribbean (eastern) side of Mexico. There are two significant areas, Punta Cancun (tip of Cancun), also known as the Hotel Zone and Playa Del Carmen. We chose to stay in Punta Cancun. The Hotel Zone is walkable and you don’t need to rent a car if you are staying there. Buses are always available to go to other parts of Cancun though you rarely will.

Read More

The two-step approach to big code modifications

Ashish on August 1, 2020

We all have to make significant code changes from time to time. Most of these code changes are large. Consider the scenario that you merged one such significant change, and then other team members made a few more changes on top. Then a major bug is detected. You desperately make the fix. It makes it in. You declare a victory, and a few hours later, your colleague notices another bug/crash/performance regression. Your commit cannot be reverted. It isn’t just about you. Many others have built on top of the change you made—the code sloths along in this broken state for a few days before you eventually fix it. Everyone has faced this issue at some point or the other.

If the code change is small, this is a non-issue, you can revert it and fix it at your own pace. Therefore, when making significant code changes, always try to do it in two different commits (pull requests). In the commit, you add the new code, add a switch (command-line flag or a constant) to turn it on, and keep that switch off by default. In the second commit, turn the switch on. Now, if there is a problem, you immediately turn the switch off and start working on a fix. No one else will deal with the broken code. It would be even better if the switch is a command-line flag since you can turn on the flag for 10% of the machines (or users) and see the behavior for a few days before rolling it out to 100%. It big teams, it is usually good to add a comment to switch mentioning when it should expire or else you will end with Uber scale problem.

There are a few cases where this cannot be done, for example, during big code refactoring. I think big code refactoring touching code written by multiple teams is almost rarely justified in a single commit.

Examples of some cases where this is useful

  1. Switching over from consuming data via v1 of some API to v2
  2. Switching over from returning computed results to stored results (for faster response time but possibly inaccurate outcome)
  3. Switching over from JSON to Protocol Buffer/Thrift
  4. Switching over from VMs to Kubernetes (don’t delete the old code yet, you might regret it)

In a remote village in Thailand…

Ashish on August 1, 2020

After renting a moped in Thailand, I stopped at a small shop to ask for a petrol pump/gas station. Instead, the shop owner handed me a bottle of gasoline for purchase.

“Must be a peaceful country where they can sell gasoline in bottles.”, I said to myself, “In most parts of the world, people would use this as a petrol bomb during violent protests and riots.”

Petrol/Gasoline sold in bottles in Thailand

Petrol/Gasoline sold in bottles in Thailand

Dealing with phone numbers in contact book

Ashish on July 9, 2020

If you are building an app that uses the user’s contact book then their certain gotchas to avoid.

Telephone country codes are prefix-free

If a country has a country code “+91”, then no other country will get a country code like “+912” or “+913”. This scheme ensures that numbers are inherently unambiguous.

Telephone numbers can have multiple representations

Since most people don’t dial internationally, telecom systems implicitly assume a domestic call. So, someone dialing 612-555-1234 in the US is dialing “+1-612-555-1234”, while the same person in India is dialing “+91-612-555-1234”. Since international dialing would be more infrequent, telecoms require unique prefix numbers like “00” to distinguish whether someone is 612-555-1234 in their country or 0061-255-51234 in Austria. In some states, even the domestic area code is not explicitly required. So, a user might have stored “555-1234” as the phone number to which telecoms will implicitly prefix the user’s area code. And if the user wants to dial beyond their area, the telecom operator would require an additional “0” prefix to mark that it is an STD call. This localization has a massive implication regarding processing cleaning and normalizing phone numbers retrieved from the user’s contact book. Both country code and area code don’t contain “0”, and usually, that’s superfluous. So, while telecoms might be OK with calling or sending SMS to “0-612-555-1234”, they will treat a number like “91-0-612-555-1234” as incorrect.

Multiple countries can share telephone codes

USA, Canada, and many countries in the Caribbean share the “+1” telephony code. The carriers would treat calls or SMS as international, though. Italy and Vatican city share “+39”.

Continuous area codes or country codes are not always adjacent

As the population grows in certain areas more than others, the codes reserved for other regions can get allotted to them. An example of that is the San Francisco Bay area, where the first 408 and then 669 was allocated on top of the existing 650 area codes to deal with the growing population.

Confirming phone number ownership

You can never trust an incoming call or incoming SMS’s phone number. Therefore, the only way to verify that the user owns a phone number is by sending them a text message or making them a phone call.

Things to do in Cusco (Peru)

Ashish on June 7, 2020

Cusco or Cuszo, an Andean city in South America, was the seat of the Inca empire and is home to world-famous Machu Picchu. I would recommend staying near the city center of Plaza De Armas (“Parade Square”). Most tourist activities are in and around the area.

Read More

Subscribe For Latest Updates

Signup for our newsletter and get member-only articles