3 ms·

For 99% of engineering organizations, internal engineering tooling is not your source of competitive advantage. Your advantage in the market comes from understa

For 99% of engineering organizations, internal engineering tooling is not your source of competitive advantage. Your advantage in the market comes from understanding the needs of your target user better than anyone else, and building a product that meets those needs. For every piece of infrastructure or developer tooling you need, you have to make a buy vs. build decision based on cost/benefit analysis. Your cost to "buy" needs to include the upfront cost of developer time to configure the software for your needs, and the ongoing support cost to make sure it continues to work. When you include this, even open source software isn't "free", although it may be cheap. Your cost to "build" includes the upfront engineering time to design & code, ongoing support time to keep it working, and opportunity costs incurred because until the system is actually ready, no one can use it, and they have to either meet their needs in some other way or simply block until the tool is complete. Very large engineering organizations like Facebook, Netflix, etc. can amortize the cost of tool and infrastructure development over thousands of developers and an enormous infrastructure budget. If a tool would make most of Facebook's developer's 3% more efficient, than it's worth staffing a team to build that tool. If better caching infrastructure could reduce Netflix's network usage by 3%, then it's worth staffing a team to build that infrastructure. If you're a small- or medium-sized business, then that math doesn't pencil out. A 3% (or even 10%) developer efficiency improvement doesn't even pay for the opportunity cost of one developer. A 10% decrease in a single dimension of your AWS bill probably doesn't pay for the developer time either. If you're at a mega-corp with a huge engineering staff: Yes, absolutely invest in tools that make your engineers more productive, especially if you've identified truly unique needs that can't be met by off-the-shelf software. If you're at a smaller business: Focus your developer energy on your user-facing problems, and almost always prefer to "buy" instead of "build" (where "buy" includes using open source software).

pm90 7y ago
I do not think it’s that simple. I understand the arguments for buying vs build. However, if you’re a technical heavy organization, relying on buying things also has its costs. You’re constrained on your product offerings because of the thing you bought. The decision is not that simple and requires a lot of work and foresight. As such, my guiding principle has been to consider the layer at which the thing you’re trying to build/buy fits. For most companies it doesn’t make much sense to build data centers and any cloud vendor will do just fine. Infrastructure is therefore somewhat easier... almost always buy. But if your product requires some kind of integration that is critical for customers, I would think hard about it before buying. The costs of integrating a bought tool are also overlooked in most of these conversations. External tools are marketed well but don’t always deliver on their promises of being easy to use or setup. Fundamentally I genuinely believe that if your product is tech heavy you absolutely need a CTO or a founding engineer who has a solid experience in building things. There is no replacement or magic pill to replace that just yet. And still, many fall into this trap.
- fiddlerwoaroof 7y ago
  > The costs of integrating a bought tool are also overlooked in most of these conversations. External tools are marketed well but don’t always deliver on their promises of being easy to use or setup. Exactly, for a lot of problem domains, the cost of integrating a third party solution is nearly equal to the cost of writing from scratch, because the hard part isn’t the problem space but the environment-specific configuration.
  - lumost 7y ago
    It's also difficult to grow and maintain a high performing engineering team centered around integrating 3rd party products. You can't spend 2 years on vendor negotiations and integrations and then expect to build the next great thing for your business.
barrkel 7y ago
What if it's a tool which halves your operating costs and eliminates a new technology stack you'd need to teach your whole dev team? What if the only tech that solves the problem is Oracle, and your business model can't cope with the costs that would incur? (I have a specific example in mind but it's private. Poor evidence for an argument; but I'll stand by the fact that some business problems require too much glue with too many moving parts, and can admit simpler, more vertically integrated solutions whose maintenance is still within reach of your average dev.)
- alexhutcheson 7y ago
  Do the math - maybe it works in your case. I'd say a key question to ask is "Do I have a technical problem that's legitimately unusual and faced by very few other businesses?" If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper. When doing the math: A common mistake is to calculate the cost of "build" as SUM(compensation of developer team on the project) over the time it would take to build the thing. You should actually use SUM(business value created by developers working on the next-highest impact items on your roadmap). In a well-run business the latter should be much higher than the former.
  - pm90 7y ago
    > If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper. How does one do that? Do other businesses just tell you how they integrated? I remain highly skeptical of this. Bigger corporations especially are quick to tout their successes but hide their failures (publicly) which makes it hard to know how happy/sad these businesses are with the decisions they made.
  - barrkel 7y ago
    What if the product doesn't work without the tech, because it's several orders of magnitude too slow with commodity public tech? (I'd end up writing an essay if I was to fill this out to full detail.)
bradleyjg 7y ago
> Very large engineering organizations like Facebook, Netflix, etc. > If you're at a mega-corp with a huge engineering staff: Netflix is an odd choice for number two on a list of two. I’d guess it has an order of magnitude fewer engineers than Facebook. So what’s the rough cutoff here? 1000 software engineers?
- alexhutcheson 7y ago
  I chose it as an example of a company that is unusually resource-intensive (in compute, network usage, storage, etc.) for how many engineers they have, so it can make sense to spend engineering more engineering resources on infrastructure than other similarly-sized orgs.
  - yibg 7y ago
    Of the FAANG companies i think Netflix builds the least of their own stuff. Still a lot more than smaller companies do and should but they tend to only build their own if there isn’t something suitable out there.

pm90 7y ago

I do not think it’s that simple. I understand the arguments for buying vs build. However, if you’re a technical heavy organization, relying on buying things also has its costs. You’re constrained on your product offerings because of the thing you bought. The decision is not that simple and requires a lot of work and foresight. As such, my guiding principle has been to consider the layer at which the thing you’re trying to build/buy fits. For most companies it doesn’t make much sense to build data centers and any cloud vendor will do just fine. Infrastructure is therefore somewhat easier... almost always buy. But if your product requires some kind of integration that is critical for customers, I would think hard about it before buying. The costs of integrating a bought tool are also overlooked in most of these conversations. External tools are marketed well but don’t always deliver on their promises of being easy to use or setup. Fundamentally I genuinely believe that if your product is tech heavy you absolutely need a CTO or a founding engineer who has a solid experience in building things. There is no replacement or magic pill to replace that just yet. And still, many fall into this trap.

fiddlerwoaroof 7y ago
> The costs of integrating a bought tool are also overlooked in most of these conversations. External tools are marketed well but don’t always deliver on their promises of being easy to use or setup. Exactly, for a lot of problem domains, the cost of integrating a third party solution is nearly equal to the cost of writing from scratch, because the hard part isn’t the problem space but the environment-specific configuration.
- lumost 7y ago
  It's also difficult to grow and maintain a high performing engineering team centered around integrating 3rd party products. You can't spend 2 years on vendor negotiations and integrations and then expect to build the next great thing for your business.

barrkel 7y ago

What if it's a tool which halves your operating costs and eliminates a new technology stack you'd need to teach your whole dev team? What if the only tech that solves the problem is Oracle, and your business model can't cope with the costs that would incur? (I have a specific example in mind but it's private. Poor evidence for an argument; but I'll stand by the fact that some business problems require too much glue with too many moving parts, and can admit simpler, more vertically integrated solutions whose maintenance is still within reach of your average dev.)

alexhutcheson 7y ago
Do the math - maybe it works in your case. I'd say a key question to ask is "Do I have a technical problem that's legitimately unusual and faced by very few other businesses?" If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper. When doing the math: A common mistake is to calculate the cost of "build" as SUM(compensation of developer team on the project) over the time it would take to build the thing. You should actually use SUM(business value created by developers working on the next-highest impact items on your roadmap). In a well-run business the latter should be much higher than the former.
- pm90 7y ago
  > If the answer is "no", then you should identify how other businesses are solving the problem and come up with really convincing reasons why you could do it cheaper. How does one do that? Do other businesses just tell you how they integrated? I remain highly skeptical of this. Bigger corporations especially are quick to tout their successes but hide their failures (publicly) which makes it hard to know how happy/sad these businesses are with the decisions they made.
- barrkel 7y ago
  What if the product doesn't work without the tech, because it's several orders of magnitude too slow with commodity public tech? (I'd end up writing an essay if I was to fill this out to full detail.)

bradleyjg 7y ago

> Very large engineering organizations like Facebook, Netflix, etc. > If you're at a mega-corp with a huge engineering staff: Netflix is an odd choice for number two on a list of two. I’d guess it has an order of magnitude fewer engineers than Facebook. So what’s the rough cutoff here? 1000 software engineers?

alexhutcheson 7y ago
I chose it as an example of a company that is unusually resource-intensive (in compute, network usage, storage, etc.) for how many engineers they have, so it can make sense to spend engineering more engineering resources on infrastructure than other similarly-sized orgs.
- yibg 7y ago
  Of the FAANG companies i think Netflix builds the least of their own stuff. Still a lot more than smaller companies do and should but they tend to only build their own if there isn’t something suitable out there.