Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buy Don't Build

jrott.com

Post reply on HN
Print view View original

171–180 of 227 posts

Re: Buy Don't Build

#171

Post by mch82 »

simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

So true! If the tool can’t be used by everyone on your team, then it is unlikely to be used.

I’ve experienced this many times.

Re: Buy Don't Build

#172

Post by lambdatronics »

rachelbythebay wrote: post #73

It’s not buy vs. build. It’s _rent_ vs. build. Unless you are actually purchasing whatever it is you’re using... and I’m guessing they aren’t doing that.

That's really incisive. Just as with rental housing, the responsibility for the maintenance gets shifted, not just the responsibility for building. It seems to me like software maintenance has gotten more and more important relative to software building over time... but it might just be an optical illusion. (I mean, Windows 3.1 didn't update itself overnight...) I wonder if this is true, and if so, what's driving it?

Re: Buy Don't Build

#173

Post by madrox »

watermelon59 wrote: post #165

I hope this doesn't get buried, because there's something that I feel like I'm a bit of a unicorn about. > The problem then with that is everyone who is working on those services is usually trying to get off of them. After all, no one wants to work on something that their boss doesn’t care about. > Yes, your CI/CD system is absolutely critical, but it’s easy for executives to not think about. This leads to a failure…

Consider that while you may care about maintaining something, whoever comes after you likely will not. Just like writing and documenting good code, solutions should last beyond a single engineer.

So yes, your skills are too valuable. All engineering skills are. That's the point of buy vs build.

If you truly feel you aren't being allowed to work on the the things you care about, it's possible you're simply in the wrong role or company.

Re: Buy Don't Build

#174

Post by bcbrown »

watermelon59 wrote: post #165

I hope this doesn't get buried, because there's something that I feel like I'm a bit of a unicorn about. > The problem then with that is everyone who is working on those services is usually trying to get off of them. After all, no one wants to work on something that their boss doesn’t care about. > Yes, your CI/CD system is absolutely critical, but it’s easy for executives to not think about. This leads to a failure…

I feel similarly. I find the most satisfaction in maintenance of an existing system, as opposed to greenfield development. Finding the optimal way to add new features inside an existing system is deeply satisfying. Improving tooling and infrastructure that leads to quality-of-life improvements across the team is very fulfilling.

Re: Buy Don't Build

#175

Post by madrox »

What this doesn't mean, though, is Buy Everything. Buying everything is also how you get poor quality and poor process. It's important to recognize what's core to your culture. It's why I prefer discussing this as a what is core vs commodity decision.

If there's a general rule for making these decisions, I haven't found one. What's helped me, though, is asking whether or not the problems my team has is any different from most other teams. Sometimes it's true, like when I was at an entertainment company working on asset management. Sometimes it isn't, like when I was at the same company figuring out an AB testing solution.

Re: Buy Don't Build

#176

Post by somuchdata »

watermelon59 wrote: post #165

I hope this doesn't get buried, because there's something that I feel like I'm a bit of a unicorn about. > The problem then with that is everyone who is working on those services is usually trying to get off of them. After all, no one wants to work on something that their boss doesn’t care about. > Yes, your CI/CD system is absolutely critical, but it’s easy for executives to not think about. This leads to a failure…

I have also seen this from time to time. We have a few engineers in my org and another on my wife's team at another company that have interests similar to yours.

I think people with your interests are really valuable. We've changed around what we index on for performance evals/promotions and what work we assign them so that we can better accommodate these sorts of work preferences and skills. If someone is happier working on an essential but unsexy, unloved corner of your systems or infrastructure, and they're also many times more productive in that area than other engineers who have no interest in it, then you might as well take advantage of it!

The key factor is making sure that the work those people are doing is truly high impact (for example, CI improvement might reduce deployment failures, improve team deployment velocity) and not simply maintenance for sake of abstract cleanliness.

Re: Buy Don't Build

#177

Post by novok »

simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

You can still run into that budgeting conversation when you build, but this time it's with an internal team.

Re: Buy Don't Build

#178

Post by dmlittle »

yagi_baba wrote: post #170
simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

I've lived that life with Datadog. I was the dev who was the most into logging so I got voluntold to be in charge of the Datadog rollout. Told everyone it was not a good idea and presented cost estimates to why, we're better off just keeping our own logs and using one of many open source projects that let you pull in logs and analyze them. But all the cool kids were on Datadog, so onto it we went. What killed us was…

I haven't used DD logs personally but from what I've been told if you send the majority of your logs straight to archive to an S3 bucket and only rehydrate the logs when you need to access them their pricing is pretty reasonable. Because you're storing the logs in your S3 bucket you can keep them however long you want and rehydrate them when you need them (say 30 days later).

The bill will still be in the low thousands but paying 30-40k per year for a logging solution is probably worth the cost if it means you don't have to maintain it. Having logs and metrics (and the APM if you're using it) all in one place is _really_ nice.

Re: Buy Don't Build

#179

Post by cinquemb »

dmlittle wrote: post #178
yagi_baba wrote: post #170

Earlier quoted context omitted.

I've lived that life with Datadog. I was the dev who was the most into logging so I got voluntold to be in charge of the Datadog rollout. Told everyone it was not a good idea and presented cost estimates to why, we're better off just keeping our own logs and using one of many open source projects that let you pull in logs and analyze them. But all the cool kids were on Datadog, so onto it we went. What killed us was…

I haven't used DD logs personally but from what I've been told if you send the majority of your logs straight to archive to an S3 bucket and only rehydrate the logs when you need to access them their pricing is pretty reasonable. Because you're storing the logs in your S3 bucket you can keep them however long you want and rehydrate them when you need them (say 30 days later). The bill will still be in the low thousan…

You have to survive as company long enough where paying 30k/month sounds reasonable for logging… esp if your revenue is nowhere near it, and are not VC funded… and you will always have to maintain your integrations at the very least.

Re: Buy Don't Build

#180

Post by trabant00 »

There are several good comments in here explaining cases and reasons to build instead of buy. But they are all techical and miss one critical thing: human motivation.

Nobody cares about your bussiness as much as you. The motivation behind your product/service provider is to take your money. Buying will always be a battle with the other party to get value for your money. They are strongly motivated to offer as little work for as much money as they can get away with because there is where profit is made.

The provider might even be more competent than you in building. But think about hiring a good programmer that just doesn't want to work vs a mediocre one that is highly motivated. I think everybody has come across these examples and knows the outcomes.

Post reply on HN