Menu
Close
EmailContact
LoginLogin
Blog Overview “I have a hammer. Where is the nail?” – Ashok Hariharan

“I have a hammer. Where is the nail?” – Ashok Hariharan

We live in interesting times. People are predicting the end of jobs (through machines), the end of diseases (again through machines), and the end of governments, and monetary/fiscal policies (through tech that run machines).

There’ll be disruptions galore in the coming years. AI, Data Science, and Blockchain will be replaced by newer and fancier buzzwords.  Startups making no money will continue being unicorns while VCs will keep looking for the next big disruption. As things change, the more they will remain the same.

Staying the same will also be the fact that startups that focus on the unsexy – things like scalability, reliability, and resiliency – will live long to tell their tales.

Don’t look for the nail

I have lived and worked through 3 economic downturns and 3 upturns during my 20 years in the tech industry. ‘Innovation’ has been a constant through each of these cycles, irrespective of which direction the graph is headed. During downturns, though, innovation tends to become a bit like a hammer looking for a nail.

For example, we have startups touting AI when the same thing can be achieved by simple excel sheets. You can train an AI model to recognize a square but you don’t really need to when a simple algorithm can do it. Sure, it’s smart for an AI to do it. But it’s smarter to look for 4 contiguous equal lines which touch each other at right angles.

Not just startups, many a VC too has fallen into the trap of putting the cart before the horse.

Take block-chain, for instance. Many problems that can be solved through blockchain can also be solved through a simple relational database. This is especially so if a central authority has control of the block or if there is no critical mass of independent ledgers.  But even central authorities now are talking about block-chains to solve already-solved problems just because it’s cool.

If one were to get one’s head out of this virtual cloud of buzzwords, one will realize that reliability and resiliency are, often, more important for mission-critical systems than the tool used to solve the problem. What is the most important piece of tech at Visa, for example? Is it the switch? Or that they can respond in seconds (latency)?

I’d say Visa works because it can handle 1750 transactions/second (concurrency) on an average, their systems are designed to handle 65K transactions/second, and they do this without ever going down.

So, as startups, while we sex up our narratives with the use of the latest buzzword, our most important work continues to be the architecture and how we build our solutions.

Can our architecture scale? Is it cost-effective? Is it reliable? How many concurrent connections can it handle?  These are our True Norths. I have been surprised to see that few VCs ever ask us these questions. Some may not even know that this is important.

Early days. Lessons for a lifetime

About 18 years ago, in the middle of the first economic downturn of this century, I used to be a hardware engineer (semiconductors) working at Laurel Networks – one of the best router startups in the US at the time.

Just two years into my job and I had already been hardwired to understand the importance of resiliency and the right architecture.

We were building a multi-service edge router, which could handle any protocol on any port.  While we spent hours building external features that would help marketability, one of the most important pieces we built then was ‘hot-swappability’. The ability to pull out any blade without bringing the system down. Basically, the machine would not require to be switched off. Not for updates. Not even for pulling out malfunctioning blades.

This feature will probably never be used in the product’s marketing campaign. But the customer would know it and will remain for life because this trust is built over time.

Our unflinching focus on concurrency (how many connections can we handle simultaneously) also led us to build our own network processor rather than taking the easier option of picking one from the industry.

My early experiences at Laurel Networks taught me that it’s not brochure talk but guaranteed uptime and resiliency that creates long-term business success.

Fast forward 18 years

IDfy is structured differently than most startups, Specifically with regard to handling tough problems. It’s structured in a way that pays less attention to the hammer and more to the nails that keep things together.

We are in a mission-critical business for our customers and we cannot afford our systems to go down. So, our focus is always on architecting a solution that’s resilient and scales well. The tools we use for that are, simply, tools.

We’ve learned this the hard way. We made mistakes. But I took a cue from my time at Laurel Networks and restructured the team differently to solve the ‘Hammer searching for the Nail’ syndrome. We are now organized around solutions and not around technologies like AI, Block Chain, Front-end, Back-end, etc.

Our teams work on solutions, end-to-end. Sometimes we use deep learning and at other times data science. Many a time the solution is just a simple algorithm because, as I said earlier, there’s no point teaching a machine to recognize a square.  More than anything else, nothing goes out without architecture review, and load & resiliency testing.

We are engineers. Of course, we love playing with the latest technologies. But that’s just a means for us. We pride ourselves more on our scalability, reliability, and resiliency. In my opinion, companies scale not because of some nifty tech but because their platforms are robust.

Google, Amazon, Uber. I am sure they scale because they focus on scalable architectures. And not so much on the latest cool hammer in town.

Share Now
Ashok Bio

Prioritize Checks Based on Your Industry

We collated insights from 2.5 million BGV cases across industries to:

– Uncover hidden risks specific to your industry
– Make smarter hiring decisions