Hacker News Reader

Comment by fader | Hacker News Reader

> My entire career is effectively to sit in meetings and tell young, passionate engineers not to build things. It’s a bit depressing, but it’s also vital.

This was the single most impactful thing I learned in my early career. I was building out monitoring systems for an in-house service we hosted on site. My boss wanted to buy some small utility to keep tabs on some minor aspect of our environment. I was a bit offended -- I could have written that myself and here he was paying someone else to do it!

He asked: "How long would it take you to write and test this?" Me: "Probably a week. Maybe a bit less, maybe a bit more if I run into something tricky." Him: "Okay. This tool will cost us $500 to buy. What's your hourly pay rate for 40 hours?"

With this I achieved enlightenment. I've never again built something at work that I could buy cheaper.

View on HN

> This tool will cost us $500 to buy. What's your hourly pay rate for 40 hours

This argument makes sense, but I worry that it’s a bit short-sighted. There are a lot of metrics that are hard to quantify where it might end up better: for one thing, I’ve found that integration costs and maintenance of integration of third-party systems are routinely underestimated: I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build. The cost of learning a proprietary toolset rather than developing experience with open tools. The cost to the industry as a whole when something like AWS or React becomes the unreflective default choice.

Is it any more shortsighted than using the "open tools" in the first place? There will be integration costs and maintenance of integration with open tools. You may not be able to pay anyone for support issues because those people may not provide the sort of customer support you expect when you pay someone.

The integration costs were part of the 40 hours. The trouble is you haven't avoided them by paying the money.

Open tools also tend to have a longer life, because a community survives even as members come and go, but one boss decides that a product isn't sufficiently profitable or the company gets bought out by a competitor and now it's discontinued and you have to start over.

And the open tools often end up with more transferable skills down the road: e.g. learning to deploy to AWS only helps with AWS; learning to deploy to k8s lets you be productive in a lot more situations.

Sure it’s shortsighted, but we’re all shortsighted, that’s the human condition. We can’t know all ends, which is why experience and judgement matter. The worst thing you could do is handwring over it though. Gather whatever data you can quickly leveraging the extent of your current expertise, make a call, implement and learn.

Its extremely short sighted. The cost is much more than (hourly wage x code hours).

There is ongoing maintenance cost that no one considers. I've never seen a project that gets built and just sails off for eternity with no maintenance or bugs. There will be times when the libraries or frameworks that built the underlying tool need upgrading. The requirements of the job might change even slightly and need a change in the code because custom tools are always built to only solve the narrow problem.

There is also the overhead of the fact that this junior developer will inevitably leave in 6 months and now someone who has never seen this project before has to pick it up to fix it, which means it will take even longer.

Plus that ignores the fact that if a developer tells you it will take 40 hours it will actually take 80-120 hours.

When you buy, the tools you buy are designed to be integrated with. They have support teams that will help you, and ongoing maintenance. Plus the tool is going to be more robust because it was built and used by many different companies with slightly different requirements. Plus someone else's developers will keep it up to date for you so you don't have to.

Internal tools are almost never worth it unless a pre-existing tool literally doesn't exist which happens when you are either solving insanely complex problems or insanely niche problems.

> the tools you buy are designed to be integrated with.

Until they change on a whim and force you to spend hours rebuilding your integration for negligible benefits. And then there’s the good old “change our vendors every five minutes because the last one wasn’t quite right”

It all sounds great in theory but it still happens that buy turns out to be a total waste if time and money.

> When you buy, the tools you buy are designed to be integrated with[...]

This makes me question if you're speaking theoretical, or actually have any practical experience.

I've been part of about a dozen "buy it" projects now, and so rarely they've been "designed to be integrated with. A lot of the time it's deeply legacy systems that have a half-hearted api slapped on top to check that box, but once you start using it you notice that everything you want to do somehow requires contacting the vendor first.

Which dovetails into an issue that, although vendors will give you the impression that their system is well tested and widely deployed, it all too often ends up being a lie. We've had quite a few instances where vendors have sold us what turned out to be something they were still building.

> I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build

I've felt this way before, but I didn't realize that I haven't factored in the risks of actually building it. I was comparing real world integration effort with an estimate, influenced by my experience of integrating with a working product.

Common sense applies, but in general I'm terrible at giving estimates unless I've done something very similar before.

I'm surprised nobody here mentioned the copyrights yet. By building it, you are gaining the copyright. By buying it, you are gaining a vendor lock-in.

If your company isn’t making money from the product then whoever owns the copyright is irrelevant.

Good engineering is building the stuff that adds commercial value to the business and buying the stuff that only adds support to the stuff that adds commercial value.

In this instance, monitoring falls into the latter category. It’s not a business differentiator.

I was told that you should only build strategic things you needed to differentiate on. Anything else, buy and adapt yourself to it.

I like your story of enlightenment though! I guess if you could genuinely build and maintain something cheaper, then why not.

Reply on news.ycombinator.com