Hacker News Reader

Comment by ownagefool | Hacker News Reader

What if the saw breaks, what if the person who knows how to use the saw leaves?

There are good answers to these problems, but I find folks who find comfort in outsourcing assume it's easier for the downstream org solve them.

Personal experience suggests it's often a false sense of security, and you often have to have your own experts anyway.

Saw the same in software. We won't get budget to patch so let's outsource. The outsourced entity also doesn't patch, because there's no business case approval to do so. The problem is usually tech is ran by finance.

View on HN

A lot of outsourcing decisions seem to be made on the premise of "what if it breaks?" It's a terrible fallacy.

Your wafer saw (or server) that is utilized 1% of the time is going to need a lot less maintenance than a shared wafer saw that is used 16 hours a day. You will actually experience a lot less downtime by investing in your own wafer saw (or your own servers) rather than outsourcing (to a foundry or a cloud provider).

I think the real draw of outsourcing is diffusion of responsibility: when it breaks, you can blame someone else.

At work, I wanted to use google sheets for our schedule because it just works: can have view only links, and it handles multiple editors at the same time gracefully. Got asked “well what if google goes down?”, so back to our problematic system of excel sheets it is :(

I experienced the opposite when Google actually went down and all of our email, docs and information went away for the day. Then one day our Internet went down and then the company bought a Microwave internet link and an off site server.

That may have been a wise person! "What if Google takes us down" (rather than goes down itself) is a valid business risk to at least consider.

Google & co are doing their best to remove themselves from a rational person's critical path. They're too big, you're too small; they're full of AI and politics, you have no recourse.

if someone had told me that "full of AI" was going to be an insult one day, I would have said they were too cynical about the glorious AI future, but in hindsight perhaps you are right

As much as GSheets is great software in theory, "just works" is something I'd never use to describe it. Google is the absolute worst when it comes to keeping stuff working outside of Gmail, Search and obviously Ads. They will silently drop functionality and randomly break things without any recourse.

Just a week or so ago, the IMPORTHTML/XML and related functions in GSheets just...stopped working. There are Reddit and Google Helpdesk threads about it so it's clearly a global issue. As far as I know, no fix has landed yet.

I had to spend a weekend writing a bunch of scripts to reimplement importing functionality so an international competition hosting more than 600 people from 28 countries wouldn't collapse on the spot. Everyone on the team, including me, was initially glad we were using GSheets as it made our work much easier - until it suddenly made it much, much harder.

> You will actually experience a lot less downtime by investing in your own wafer saw (or your own servers) rather than outsourcing (to a foundry or a cloud provider).

Analogy doesn't work; "in-sourcing" of previously-IaaS resources as a cost-cutting measure, is used almost exclusively for "base load" (vs. elastic load, which is the comparative advantage of IaaSes); and so your in-house servers are usually running pinned at 100%. So the hardware components will wear out just as fast, if not faster, than the IaaS's servers will; and when they do, your ops team won't have as many spare parts on hand as the IaaS does; nor the ability to live-migrate the enforced VM to another exactly-equivalent substrate host in the fleet (which was already warm) to avoid downtime altogether.

Also, apart from that, there are economies of scale in reliability. Your in-house backups are probably just a ZFS pool or a RAID5+1 array or something. They're certainly not hosted within a 17+-copies Dynamo-ish system, the way most IaaS object storage (incl. archival storage) is, because the costs of doing that in-house are ridiculous.

What do you think about external core dependencies? For example, people are starting to use Okta/Auth0 for the authentication core of their apps.

Obviously, this puts them at the mercy of the okta if anything goes wrong with IdM. But then again, people are very bad at doing auth.

> 17+-copies Dynamo-ish system

Are you implying that having more than 3 copies is somehow more reliable? Cause that sounds pretty insane.

Rarely using a tool risks it rusting/rotting/obsoleting on the shelf, and if it is expensive you are paying a lot of depreciation. You buy a chraler consumer version that breaks, or an expensive professional model that depreciates. The time share model makes sense.

>> There are good answers to these problems, but I find folks who find comfort in outsourcing assume it's easier for the downstream org solve them.

IMHO a lot of outsourcing decisions are based on the idea that someone else can do it better than we can. This is demoralizing and will eventually become a self-fulfilling prophecy as the most competent people get frustrated and leave. I suspect it may also be projection from managers that are in over their head or don't understand what their own people are saying. And then of course there are times when it's true that someone else can do it better.

> you often have to have your own experts anyway.

+1 on this

IME the most successful outsourcing arrangements revolve around scale of work, not substituting an entire department. Keeping the amount of in-house experts lean and having them manage outsourced resources. So it is more of a tool for someone internal who has the needs organized rather than a dependency on a 3rd party to know what is best for you

> What if the saw breaks, what if the person who knows how to use the saw leaves?

Then you go and fix that as you have the means to do that.

Were it outsourced and you can only wait for the vendor to do it

> Saw the same in software. We won't get budget to patch so let's outsource. [...] The problem is usually tech is ran by finance.

Same. Where actually, the budget is right there, it's just a matter of choice and priorities: do what's right now or invest 10x in it later because you didn't take care of it when you ought to.

I've been on both sides of the argument: "budget" is a magic word for those who want to skip responsibility for their choices.

Yes and no.

Sometimes the budget is yours sometimes you're sitting in meetings upon meetings with someone else deciding there's no immediate ROI so no budget for you.

So sure, the company is always to blame, but unless we're arguing the individual was not convincing enough, the person citing budget may not be choosing alone where to allocate it.

On the bright side, inefficient companies leave the market open for the rest of us. :)

This. For every short-sighted decision made by the finance overlords, I've seen ten failures on the tech wizards' part to plan for their own future well-being. Laziness keeps them from even making a case.

As someone employing a lot of engineers right now, one of the problems is that engineering will just keep requesting resources ad infinitum if there’s no budgetary limit. The constraints of the business are actually always financial, and without proper financial modeling you’ll cease to have a business.

This is true in process scaling no matter the process.

ime the primary reason to outsource is to get rid of the responsibility and the long-tail due-diligence that comes with it.

Also the blame. On prem outage? IT management is in the hot seat for a fix. AWS outage? Well, major us-east-1 outages make the news so the blame is more diffuse. And even outside of that, it's much harder for anyone internally to blame IT management for the outsourcing, so long as they were smart and got the CFO to take credit for the cost savings of going cloud or something.

HN often underestimates how much of enterprise IT, and large business generally, is about making sure that upsides are concentrated enough your management chain can take responsibility, and downsides are either diffuse enough or deflectable enough that your management chain can avoid responsibility.

Then you go out of house until the saw can be repaired or you can recruit a new employee to run it. If it's really to your advantage to have the capability in-house, no one will bat an eye.

Reply on news.ycombinator.com