Our Team WON the VTA hackathon…….!!!!!
Updates from October, 2014 Toggle Comment Threads | Keyboard Shortcuts
implement the twitter login in ur application.
PODDLE attack !!!!!
wait listed for Fabric released by twitter…excited for it.
if u r migrating from 3.x to 4.x express comment the route in ur .js code to run it successfully and also replace the middleware body-parser with the new one.
CAP Theorem: RevisitedWritten by Robert Greiner on August 14, 2014
Note: Close to two months ago, I wrote a blog post explaining the CAP Theorem. Since publishing, I’ve come to realize that my thinking on the subject was quite outdated and is no longer applicable to the real world. I’ve attempted to make up for that in this post.
In today’s technical landscape, we are witnessing a strong and increasing desire to scale systems out when additional resources (compute, storage, etc.) are needed to successfully complete workloads in a reasonable time frame. This is accomplished through adding additional commodity hardware to a system to handle the increased load. As a result of this scaling strategy, an additional penalty of complexity is incurred in the system. This is where the CAP theorem comes into play.
The CAP Theorem states that, in a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance – one of them must be sacrificed. However, as you will see below, you don’t have as many options here as you might think.
- Consistency – A read is guaranteed to return the most recent write for a given client.
- Availability – A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).
- Partition Tolerance – The system will continue to function when network partitions occur.
Before moving further, we need to set one thing straight. Object Oriented Programming != Network Programming! There are assumptions that we take for granted when building applications that share memory, which break down as soon as nodes are split across space and time.
One such fallacy of distributed computing is that networks are reliable. They aren’t. Networks and parts of networks go down frequently and unexpectedly. Network failures happen to your system and you don’t get to choose when they occur.
Given that networks aren’t completely reliable, you must tolerate partitions in a distributed system, period. Fortunately, though, you get to choose what to do when a partition does occur. According to the CAP theorem, this means we are left with two options: Consistency and Availability.
- CP – Consistency/Partition Tolerance – Wait for a response from the partitioned node which could result in a timeout error. The system can also choose to return an error, depending on the scenario you desire. Choose Consistency over Availability when your business requirements dictate atomic reads and writes.
- AP – Availability/Partition Tolerance – Return the most recent version of the data you have, which could be stale. This system state will also accept writes that can be processed later when the partition is resolved. Choose Availability over Consistency when your business requirements allow for some flexibility around when the data in the system synchronizes. Availability is also a compelling option when the system needs to continue to function in spite of external errors (shopping carts, etc.)
The decision between Consistency and Availability is a software trade off. You can choose what to do in the face of a network partition – the control is in your hands. Network outages, both temporary and permanent, are a fact of life and occur whether you want them to or not – this exists outside of your software.
Building distributed systems provide many advantages, but also adds complexity. Understanding the trade-offs available to you in the face of network errors, and choosing the right path is vital to the success of your application. Failing to get this right from the beginning could doom your application to failure before your first deployment.
No Market Validation
We wanted to build zomato like platform for school listing & reviews but realized that parents research for schools in admission days only. Then we thought of doing something else for education industry. With little knowledge about schools, we decided to build online collaboration platform for parents and teachers. We thought this was much desired product by education industry which can help building great relationships between parents and schools.
Do market research (product-market fit) before writing first line of code
We sowed the first seed of failure when we started building product without validating product-market fit. We could have done better things if we had few school signups before starting product development.
Waiting for perfect product launch
In my experience, there is no perfect product in startups, my suggestion is to keep building and keep releasing. We were not aware of Lean Startup concept which says, build fast — fail fast — fail cheap, and keep iterating until you success. Unfortunately, we kept investing time in building awesome product with great user experience and mind blowing features.
Launch MVP (Minimum Viable Product) as early as possible and keep improving product with feedback from early customers
We could have saved lot of resources with early launch of product. Customers should have given opportunity to test demo version, even with shitty user experience and half baked features. We spent almost half year to come up with first demo account, which could have been done in first month itself.
Following foot steps of competitors
When we launched our product we confronted with harsh reality, customers were not interested in our offerings. Then we started looking out what our competitors are selling. This was the opportunity to focus on USP (unique selling proposition) but we started building what our competitors were selling.
“Focus on something you are very good at — but your competitors are not”
We hired people from competitor’s sales team, we tried to sell with similar pitch, we prepared similar marketing material, we even tried to align our product features with competitor. Our efforts failed because we could not compete with competitors at points where they were good at — but we were not!!
Spending money on unwanted things
We spent too much on unwanted things like office, furniture and electrical appliances. We could have optimized expenses by running operations from our home.
“Spend money only if it helps in releasing software fast, test fast (customer acquisition) or pivot fast”
Startups have to spend money on hiring talent and there is no alternate unless you have time to do things yourself. Actually money was not primary reason of our failure but we could have done much more with same money, like hiring more smart developers to fast build & test our product.
Lack of Vision
Ultimately we lost the vision!! We forgot why we started company and where it should be in two years or five years. We were saying something and doing something else. We wanted to collect students data from 1000′s of schools but we were trying to sell to top schools only. We were not having any clue of our key growth metrics, unit economy, sales conversion ratios or product road-map.
Startups should keep eagle-eye focus on Vision and keep changing strategies and products to achieve end goal.
Influence of wrong people also disturbed our thought process. We discussed things with people who had no prior startup experience but they were successful in corporate job. My suggestion is, do not to follow advice of corporate guys, I am not saying they are wrong but things works differently in startups.
Startups have to explore their own growth path, don’t be afraid to experiment with new things.
I believe every startup come at a stage where hard decisions are taken. Delay in decisions impact badly on startup growth. Founders should sit together, discuss deeply about issue, take firm decision and move on!! There are good decisions and there are bad decisions.
If Founders are clear of what they want to achieve then they can take quick and efficient decisions otherwise they take decision tonight and tomorrow morning they want to change it.
Something similar happened with us when we were to decide for sales partnerships, establishing new sales channels, product roadmap, equity allocation to team members, pivoting product and finally during critical decision of running or shutting down company.
With time, we (founders) had differences in thought process, one of us wanted to try new unexplored things and other wanted to follow processes of big successful companies. One of us believed in open culture where anyone can contribute in any area but other believed in closed culture where two teams (dev & sales) should not share know-hows of each other.
This friction and lack of cohesiveness was also reason of delayed decisions, hence one more step towards death of startup!!
Startup should genuinely invest time in finding good mentors. We could not find mentors for our-self or honestly we have not tried hard enough. Mentors can be really helpful in critical times when startup needs expert advice, connection in network and resolving internal conflicts.
Now we are not working at SchoolGennie but it has been a great journey so far. I am really grateful to my co-founder Amit, who trusted my capabilities and gave me opportunity to work with him. He was instrumental to bring me out of corporate job and introducing me to amazing world of startups.
Failures are not always bad if we know how to handle post-failure situation and apply learnings in future, on positive side I know some ways things don’t work and I will avoid repeating my mistakes. SchoolGennie experience actually helped me getting into my current startup, PocketScience, where I joined as co-founder.