5 ms·

This all boils down to "make cost benefit decisions". The problem is that maybe cost benefit decisions are really hard. To understand the cost of map reduce, f

This all boils down to "make cost benefit decisions". The problem is that maybe cost benefit decisions are really hard. To understand the cost of map reduce, for example, I probably have to use it at least once. High cost just to understand something. And I have to understand the alternatives, so I'm trying those out too. You know what's faster? Signaling. When large companies say "this approach works for us" it's really cheap and easy to say "Well that's probably good enough then". Do you lose out on efficiencies by not fully understanding the problem? Duh. But probably not as much as understanding an entire domain for every technical decision you make. The steps outlined, particularly 1,2,3,4, are really expensive for every single technical solution. Reading multiple technical papers for a db is probably more costly than just acquiring customers, hitting scaling limits for your uninformed choice, and moving to a new db based on a somewhat more in depth approach or hiring a consultant. Let's assume that if you guessed a technical solution, the cost of 'guessing' is 0, and the cost of picking the wrong solution is 'low'. Should I waste time doing anything other than guessing? If the cost of 'do what google does' is 0, or near 0, and better average chance of working, why not pick it? Unless the stakes are high, putting that kind of investment into every technical decision just seems needless. And they arguably have to be very high to offset the cost, and I would state that determining those costs upfront itself may be difficult and error prone. For every mis-guess listed in that article, how many new customers did they acquire due to making the right 'guess' based on signaling from other companies? The companies clearly hadn't gone under from those bad decisions, so would it really have been the right call to have invested in such deep thinking about the problem early on? Not sure I believe what I wrote entirely, just thinking out loud.

entee 8y ago
This. Some of the biggest mistakes I've made have been too much "thinking". The article makes good points, but seems to argue all these newfangled systems have a very high cost if adopted in the wrong situation. I would argue the cost is probably not that high especially in a managed cloud and many decisions can be tweaked later. In other words, if a Postgres based solution takes 1 month to build, and a CloudSpanner/Aurora/pick-cloud-managed-sql-DB solution takes 1 month to build, just pick one. Most of the time, if you make a mistake, you'll find out when you have more customers/funding/engineers/knowledge of what actually matters.
- staticassertion 8y ago
  Yes, I think it's really easy to look at a project, after it has scaled, and go "wow they made such bad technical decisions! Why didn't they learn more about this?" and ignore that the system is running, they have customers, a business, and they're solving the problem when it has become important to do so. I've seen lots of time wasted overthinking solutions only to find out that the requirements were changed a month before release, or customers would use the system completely differently than expect.
wahern 8y ago
> Let's assume that if you guessed a technical solution, the cost of 'guessing' is 0, and the cost of picking the wrong solution is 'low'. Should I waste time doing anything other than guessing? If the cost of 'do what google does' is 0, or near 0, and better average chance of working, why not pick it? That makes more sense if you s/cost/risk/. The answer to why you shouldn't just do whatever Google is doing is because trying to copycat the leader is the one thing that will guarantee your _failure_ in the market place. Same with AWS. AWS Lambda was built to solve existing problems. Everybody will use it to solve the same problems it's designed for, but only a tiny number of people will actually succeed in the marketplace because it just becomes a numbers game. If you want to win you have to play a different game--look for problems where AWS Lambda is a poor fit. If you're doing the same thing as everybody else you're by definition just reinventing the wheel. Why bother?
- staticassertion 8y ago
  I mean cost in terms of 'time to make a decision', without considering 'cost of making the wrong decision', which is closer to risk. > The answer to why you shouldn't just do whatever Google is doing is because trying to copycat the leader is the one thing that will guarantee your _failure_ in the market place. The article seems to demonstrate the opposite - decisions following the leader, and paying for it later, but surviving in the interim. > If you're doing the same thing as everybody else you're by definition just reinventing the wheel. Why bother? I don't really agree. When it comes to something like a DB or architecture, that's probably not where you need to be inventing new solutions - products are rarely sold based on their technical implementation, and more about the results they drive. If you were building a new Google search, and you used all of the same tech, that's probably a bad idea. But if I'm building a product for a completely isolated domain, who cares if it's solved using the same tools that Google solves search? Regarding lambda, there's likely tons of room for competitors even within a domain to implement off of the same technology - again, it's just a tool, and not likely to be the differentiator.

entee 8y ago

This. Some of the biggest mistakes I've made have been too much "thinking". The article makes good points, but seems to argue all these newfangled systems have a very high cost if adopted in the wrong situation. I would argue the cost is probably not that high especially in a managed cloud and many decisions can be tweaked later. In other words, if a Postgres based solution takes 1 month to build, and a CloudSpanner/Aurora/pick-cloud-managed-sql-DB solution takes 1 month to build, just pick one. Most of the time, if you make a mistake, you'll find out when you have more customers/funding/engineers/knowledge of what actually matters.

staticassertion 8y ago
Yes, I think it's really easy to look at a project, after it has scaled, and go "wow they made such bad technical decisions! Why didn't they learn more about this?" and ignore that the system is running, they have customers, a business, and they're solving the problem when it has become important to do so. I've seen lots of time wasted overthinking solutions only to find out that the requirements were changed a month before release, or customers would use the system completely differently than expect.

wahern 8y ago

> Let's assume that if you guessed a technical solution, the cost of 'guessing' is 0, and the cost of picking the wrong solution is 'low'. Should I waste time doing anything other than guessing? If the cost of 'do what google does' is 0, or near 0, and better average chance of working, why not pick it? That makes more sense if you s/cost/risk/. The answer to why you shouldn't just do whatever Google is doing is because trying to copycat the leader is the one thing that will guarantee your _failure_ in the market place. Same with AWS. AWS Lambda was built to solve existing problems. Everybody will use it to solve the same problems it's designed for, but only a tiny number of people will actually succeed in the marketplace because it just becomes a numbers game. If you want to win you have to play a different game--look for problems where AWS Lambda is a poor fit. If you're doing the same thing as everybody else you're by definition just reinventing the wheel. Why bother?

staticassertion 8y ago
I mean cost in terms of 'time to make a decision', without considering 'cost of making the wrong decision', which is closer to risk. > The answer to why you shouldn't just do whatever Google is doing is because trying to copycat the leader is the one thing that will guarantee your _failure_ in the market place. The article seems to demonstrate the opposite - decisions following the leader, and paying for it later, but surviving in the interim. > If you're doing the same thing as everybody else you're by definition just reinventing the wheel. Why bother? I don't really agree. When it comes to something like a DB or architecture, that's probably not where you need to be inventing new solutions - products are rarely sold based on their technical implementation, and more about the results they drive. If you were building a new Google search, and you used all of the same tech, that's probably a bad idea. But if I'm building a product for a completely isolated domain, who cares if it's solved using the same tools that Google solves search? Regarding lambda, there's likely tons of room for competitors even within a domain to implement off of the same technology - again, it's just a tool, and not likely to be the differentiator.