Live data from Hacker News

Buy Don't Build

jrott.com

31–40 of 227 posts

Re: Buy Don't Build

#31
post #2

I agree. If you are in decision making position, I struggle to see why would you want to spend so much energy installing Prometheus + Grafana stack instead of just using DataDog. Even worse if your company attempts to build Prometheus/Grafana from scratch. Just why? What a huge waste of money. If it contributes to your core business then ok, I can see why you may want to build custom solutions.

Interesting you should bring this up as we are currently in the process of moving from Datadog to Prometheus/Grafana. What we've found is all the time you save in not setting up Prometheus we lose in support tickets to Datadog to get them to explain undocumented functionality and hidden "magic" they put in place. With Prometheus/Grafana the answers are always out there because of the sheer number of people out there. We've even resorted to sending known metrics on known intervals just to understand what Datadog does differently for monitors vs graphs. Also the majority of the time for a monitoring system is not spent on setting it up but rather on generating the dashboards and alerts.

Also with all buys systems there is a hidden costs in managing the legion of user accounts to access these new services. It's rarely as easy as just setting up SAML or single sign on.

The final thing that people never talk about is cost. Yes there is the cost of an engineer to set it up but often that costs is cheaper than the bought service. This is especially true of pay per api call type services.

Re: Buy Don't Build

#32

I own a Screenshot API service (shameless plug: https://getscreenshot.rasterwise.com/ ) and this exactly the argument that I make for small utilitarian services like mine. You shouldn't build them because buying them is several orders of magnitude cheaper. I have a small paragraph from a blog post where I explain this with some math that is probably crappy but captures the idea: "When you spend time in areas that are…

That's cool. How much money do you make with that service?

About $500 USD/month. Haven't put too much effort to promote it though.

Re: Buy Don't Build

#33
Nonsense without a context.

Sometimes "building" means writing 6 shell scripts (each <10 LoC) and "buying" means getting CKA/CKAD certificates for all people involved and spending half a year on training.

Re: Buy Don't Build

#34
post #3

I'm totally on board with the overall message that building (i.e. engineering) your own internal tools come with lots of overhead, but take issue with this one point: > My counter-argument to that is there is also lock-in with internal systems. The most common version of this is the keeper of the spreadsheet. The author then disparages spreadsheets as becoming the exclusive domain of one employee who wouldn't want pr…

It's also a strawman argument.

The alternative could instead be a system with open standards that many vendors implement, and only relying on standardized behavior.

This works to some extent with for example SQL or C, where you can migrate from one DB or compiler to another with limited effort.

Re: Buy Don't Build

#35
I'm a little confused. When I have to build software (for a client), it's usually to support some business process or make it automated or whatever.

What am I supposed to buy, except some PDF/Excel/whatever library every now and then?

But maybe I'm just not the target audience for this article.

Re: Buy Don't Build

#36
I think there is a balance in the "Yak Shaving" business... There is a swaying "the best code is the code you did not write".

Re: Buy Don't Build

#37

One of the few things I appreciate from my abusive first boss was making me acutely aware of the value of my own time. He was incredibly stingy with money and always wanted to know how much it would cost him to have his engineering team implement something vs how much it would cost to buy it and integrate it. Admittedly he was pathologic about this to the point of having us create a timer that counted in pounds sterl…

I had a similar client early in my career. Working for him was a love/hate relantionship. He tripled my hourly rate telling me my time was highly valuable but then had very high standards and aggressive timelines.

Re: Buy Don't Build

#38

All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.

Exactly. I've even had this happen with things like CSS, where a master stylesheet changes somewhere upstream on another server, and hundreds of hours of my own custom, vendor-supported modifications now make my web application or website look like doo-doo. Plus maybe I'm weird but I think it's enough to love the energy you can get from building something. It's fun. And considerable portions of work should be fun. Es…

> I think it's enough to love the energy you can get from building something

I think this is good if you can get there. The IKEA of software is pure dopamine. If had to grow and saw those trees less so. If you are pouring concrete and get it delivered, pure dopamine. If you have to crush the aggregate by hand, less so.

Re: Buy Don't Build

#39
I have to disagree.. Not everyone has enough time to learn "ready" systems either, they can get pretty overwhelming. When I decide to build instead of buy, it's mostly because I don't believe in the design of the product that is favored by thousand people with reason being "it just sounds cool".

Re: Buy Don't Build

#40
From an engineer perspective there is a learning opportunity that can’t be underestimated. If you have free time to build it’s always interesting how much you can grow by doing it yourself. However, if you are working for a startup and time to market is essential, than buy it for sure.
Post reply on HN