4 ms·

I would say the biggest practice that smaller companies should not emulate is "rolling your own" otherwise known as "not invented here". For a large FAANG compa

by zaphar 5y ago

I would say the biggest practice that smaller companies should not emulate is "rolling your own" otherwise known as "not invented here". For a large FAANG company creating your own versions of things can potentially pay off and if they don't those companies can eat the investment cost with out too much trouble. Smaller companies should focus on the business problems though instead of rolling their own database, orchestration, or programming language. At a large enough size doing any of those things may pay off but when you are smaller they are just a distraction from your core business.

avmich 5y ago
I'd recommend the opposite. Learning tons of 3rd party tools and relying on multitude of external dependencies is dangerous, especially when company can't afford sudden downtime or security breaches. For simple enough tasks, like many those tools on the market are solving, it's arguably better to create a tailored version in-house than to learn the approximation from the market, then spend resources associated with long-term costs - upgrades, learning, payments... Focusing on business problems is good and all, but if you're ruthlessly outsource everything else, you'll find yourself in the middle of patchy solution with little control and no end of gotchas - technical and otherwise. If you plan to use 10% of a tool and going to pay for 100%, for startups it should be a no-brainer decision.
- closeparen 5y ago
  If you can’t afford downtime and security breaches, you can’t afford to be shipping an amateur and half baked version of something that externally is backed by a bigger and more skilled team than your entire engineering org. You can potentially simplify your approach so you don’t need anything in the category.
- zaphar 5y ago
  There is always going to be some nuance. But there is a big difference between implementing your own database and implementing your own deployment script. Starting out small and adding tools to your toolbox is going to be a judgement call. But too much NIH and you spend all your time reimplementing Bigtable or Cockroachdb instead of building your product.
  - avmich 5y ago
    True. It's just my observation that today's approach is mostly "let's focus on our value proposition and outsource everything else" to the degree it becomes detrimental for the product and company. Surely if you're trying to re-implement PostgreSQL, it's, to put it mildly, interesting (though even here there could be discussions - perhaps you just need a specific slice of functionality?). But for many, many other things, which are at worst a few man-weeks works - and sometimes man-hours, if you're sober with requirements - you could win with the other approach. If you're adding something external, just make sure you're serious about that - documentation, technology background vetting, training, all those things. Otherwise the opinion that "external solution produced by team bigger than ours" is better could be based on an illusion.

by zaphar 5y ago

avmich 5y ago

I'd recommend the opposite. Learning tons of 3rd party tools and relying on multitude of external dependencies is dangerous, especially when company can't afford sudden downtime or security breaches. For simple enough tasks, like many those tools on the market are solving, it's arguably better to create a tailored version in-house than to learn the approximation from the market, then spend resources associated with long-term costs - upgrades, learning, payments... Focusing on business problems is good and all, but if you're ruthlessly outsource everything else, you'll find yourself in the middle of patchy solution with little control and no end of gotchas - technical and otherwise. If you plan to use 10% of a tool and going to pay for 100%, for startups it should be a no-brainer decision.

closeparen 5y ago
If you can’t afford downtime and security breaches, you can’t afford to be shipping an amateur and half baked version of something that externally is backed by a bigger and more skilled team than your entire engineering org. You can potentially simplify your approach so you don’t need anything in the category.
zaphar 5y ago
There is always going to be some nuance. But there is a big difference between implementing your own database and implementing your own deployment script. Starting out small and adding tools to your toolbox is going to be a judgement call. But too much NIH and you spend all your time reimplementing Bigtable or Cockroachdb instead of building your product.
- avmich 5y ago
  True. It's just my observation that today's approach is mostly "let's focus on our value proposition and outsource everything else" to the degree it becomes detrimental for the product and company. Surely if you're trying to re-implement PostgreSQL, it's, to put it mildly, interesting (though even here there could be discussions - perhaps you just need a specific slice of functionality?). But for many, many other things, which are at worst a few man-weeks works - and sometimes man-hours, if you're sober with requirements - you could win with the other approach. If you're adding something external, just make sure you're serious about that - documentation, technology background vetting, training, all those things. Otherwise the opinion that "external solution produced by team bigger than ours" is better could be based on an illusion.