3 ms·

The common mistake I see people make is presuming that the "buy" will deliver on their end of the deal. When they don't, that engineer making $100k is spending

The common mistake I see people make is presuming that the "buy" will deliver on their end of the deal. When they don't, that engineer making $100k is spending a lot of time (i.e., and money) writing support tickets, desperately trying to get it escalated to someone on the vendor's side who can actually do something, as inevitably you have to first peel away the layers and layer of customer support, account managers, "solution" people who aren't actually capable of fixing anything. (Even for some inanely simple questions, sometimes, things that I think "wow, a support rep. should actually be able to answer this, it's not a highly technical problem for once" and then, nope, it has to get escalated to eng., inevitably.) The amount of my own salary that has gone towards "Azure support ticket monkey" is frankly frightening. And I have never once seen that included in the estimate for "buy". Many of the "build" solutions I have run require <1 engineer to maintain. When they require maintenance (whether due to something needing an upgrade, new feature request, etc.), yeah, there's maybe a two or three week piece of work, but then there are months long spans where it just sort of hums along in the background. Even outside of "support", I still end up having to dedicate eng time to "buy" solutions, to fill in gaps in their implementation. (E.g., an artifact store having read-your-writes bugs. Heck, Github Actions ("buy" of CI) has so many bugs in it that we hit in the course of adopting it…)

jack_h 4y ago
You are correct in the fact that 'buy' doesn't mean zero cost. At scale both 'build' and 'buy' suffer from the same problem, overhead. 'Build' has the overhead of the initial development, documentation, testing, the follow-on maintenance, refactoring, etc. If you have one 'build' item in your code base that's not a huge amount of overhead in the long term. If your entire code base is custom you have a scaling problem; you will end up spending a lot of your development effort on this overhead rather than revenue generating work. Ideally 'buy' lets you go further but you will eventually reach the same scaling problem. The overhead here is in research, prototyping, integration, bugs, workarounds, etc. As you have more and more external dependencies this overhead goes up until you are in the same boat as above. Also not all dependencies are created equally; some have more overhead than others. For background I do embedded software where basically everything is 'build'. When I say everything I mean file systems, network stacks, hardware abstraction layers, communication protocols, testing frameworks, and so on. I would estimate that roughly 90-95% of what my team does is maintain all of the 'build' pieces, none of which makes a profit but all of which are required for the features that do make a profit; we just don't have time to work on the latter unless we take more shortcuts in the former. So when you say that a 'build' solution takes < 1 engineer to maintain consider what that looks like in 5, 10, and 25 years. The overhead stacks up, the industry changes, institutional knowledge is lost, hiring and onboarding becomes more difficult, and so on. Of course my bias is in systems that last a long time where it's incredibly difficult to replace custom bits that have outlived their usefulness with third party bits.

jack_h 4y ago

You are correct in the fact that 'buy' doesn't mean zero cost. At scale both 'build' and 'buy' suffer from the same problem, overhead. 'Build' has the overhead of the initial development, documentation, testing, the follow-on maintenance, refactoring, etc. If you have one 'build' item in your code base that's not a huge amount of overhead in the long term. If your entire code base is custom you have a scaling problem; you will end up spending a lot of your development effort on this overhead rather than revenue generating work. Ideally 'buy' lets you go further but you will eventually reach the same scaling problem. The overhead here is in research, prototyping, integration, bugs, workarounds, etc. As you have more and more external dependencies this overhead goes up until you are in the same boat as above. Also not all dependencies are created equally; some have more overhead than others. For background I do embedded software where basically everything is 'build'. When I say everything I mean file systems, network stacks, hardware abstraction layers, communication protocols, testing frameworks, and so on. I would estimate that roughly 90-95% of what my team does is maintain all of the 'build' pieces, none of which makes a profit but all of which are required for the features that do make a profit; we just don't have time to work on the latter unless we take more shortcuts in the former. So when you say that a 'build' solution takes < 1 engineer to maintain consider what that looks like in 5, 10, and 25 years. The overhead stacks up, the industry changes, institutional knowledge is lost, hiring and onboarding becomes more difficult, and so on. Of course my bias is in systems that last a long time where it's incredibly difficult to replace custom bits that have outlived their usefulness with third party bits.