Hacker News new | past | comments | ask | show | jobs | submit login

> For one, large government software projects are almost always disastrous, even in developed countries.

The same tends to be true for large corporate software projects.

As a fairly recent example: https://www.theregister.com/2019/04/23/hertz_accenture_lawsu...




Right, but there's a self-correction here, which is that Accenture gets fired if they do a bad job. The govt has a monopoly and so there's little self-correction - too many layers of indirection between the everyday voter and Amazon's outcome.


Governments get fired fairly regularly.


Through multiple layers of indirection and obfuscation. A democratic vote every 4 years is noisy when it pertains to one specific outcome (say, Amazon's performance right now) since that vote also contains information for numerous unrelated things. Private ownership means a very tight feedback loop between performance and governance.

It's basically why collective ownership of complicated things has never worked. Except for perhaps the army, which costs an absolute fortune.


>"It's basically why collective ownership of complicated things has never worked"

Except also the roads, railroads, airports, ports, oil pipelines, nuclear weapons and reactors, GPS and weather satellites, chunks of the energy grid, NASA, a national postal service, social security numbers, and so on


> NASA

Which proves my point. Look at the innovation that SpaceX has created with VTOL rockets. If it was left purely up to nationalized bodies this would have never happened (or maybe, it would have taken 50-100 years). The incentives and desire for economic efficiency just simply aren't there. Government wants flashy one-off wins that generate publicity and votes, if it wastes a few billion and doesn't scale there isn't any consternation. The entire mindset top to bottom is completely inconsistent with VTOL rockets.

> roads, railroads, airports, ports, GPS,

The argument for these being nationalized is that these are goods that are prone to natural monopoly and some of those are largely non-excludable in the case of roads.

None of those arguments apply to Amazon. eBay is a substitute for marketplace, Azure is a substitute for AWS, etc.

These are also much simpler than Amazon. Could a government have created AWS? Could a government create an iPhone? It's a rhetorical question because all know that the answer is no. Even if they could in terms of capability, they won't because the incentives aren't right. And if they tried, they'd do it incredibly inefficiently and be outcompeted in am embarrassing fashion by a private alternative (e.g. eBay), with the difference being subsidized by the taxpayer.

> nuclear weapons

In the case of nukes, the argument is that the government has a monopoly on force (which is also why the army should be nationalized).

And I already conceded that the army was well-run, although at a ridiculous level of cost (which is another byproduct of nationalization).

> weather satellites

Built by a private company.


> roads

Heavily subsidize car use, incentivizing urban sprawl and carbon emissions. Repairs take too long. Design is convoluted.

> railroads

Usually privately owned

> Airports

TSA

> Ports

Jones Act

> Oil pipelines

Usually privately owned

> nuclear weapons

Oh yeah, what a great thing to have around. Really provide a service to citizens.

> nuclear reactors

Often privatized

> national postal service

Junk mail. Also, have you heard of the American Letter Mail Company? They competed so well, the government essentially banned competition in the letter delivery space.

> social security numbers

Insecure, easy abusable. Not meant for identification, but used for that anyways.


>The same tends to be true for large corporate software projects.

Yes, but it's not true for Amazon, the topic of conversation.


Isn't the topic of conversation that Amazon's successful software projects have had potentially disastrous side-effects?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: