The Myth of the Barter Economy (2016) - <AUTHOR> https://www.theatlantic.com/business/archive/2016/02/barter-society-myth/471051/ <comment><USER2> Ancient history is very interesting in these matters: back in the Bronze Age, kings such as Pharaoh and the Hittite, Assyrian, Minoan kings actually did international trade through "gifts".

For instance the Pharaoh was in need of cedar wood, so he would write to the King of the Assyrians in Sumerian (the _lingua franca_ of the time) "Dear cousin, I would like to send you some gifts but I'm out of boats. Cheers, Ramses".

To which his "dear cousin" would reply "Dear cousin, I'm sending you these cedar logs so that you can build these boats you need. Did I tell you that drought has hit Niniveh and the corn is scarce? Yours, Sennahcherib". Then Pharaoh would send back boats full of grain, and so on.

<comment><USER3> The thrust of your comment is more or less correct, but you make several significant errors in the details.

Akkadian, not Sumerian was the language of international diplomacy in the period you speak of. Sennacherib came later in the Iron Age. And if the Egyptians needed cedar, they'd write to Byblos (which during the New Kingdom, was a tributary state more often than not), not Assyria.

<comment><USER4> More, please.

<comment><USER5> Would be awesome to get a good book referral for this indeed.

<comment><USER6> The original comment is almost certainly thinking of [https://www.amazon.com/dp/0199858683/](https://www.amazon.com/dp/0199858683/) (Brotherhood of Kings: How International Relations Shaped the Ancient Near East).

It's a very good book.

A minor theme is indeed that Mesopotamian city-kings had a hard time trading with Egypt. Mesopotamia seems to have produced mostly textiles, which Egypt made domestically. What Egypt needed from international trade was copper and wood.

All the Mesopotamian city-kings wanted gold, though, which came from Egypt. They could get this one time, by marrying a daughter to the Pharaoh. We have an example of Pharaonic correspondence with a king who repeatedly asked for unworked gold, finally sent a daughter over, received a mountain of gold in return, and concluded by complaining that the gold had been worked (into statues).

I assume many of those statues got melted down.

There is some discussion in [https://www.amazon.com/dp/0670022667/](https://www.amazon.com/dp/0670022667/) (Carthage Must Be Destroyed: The Rise and Fall of an Ancient Civilization) of how the Phoenician city-states of the bronze age (source of cedar wood to Egypt) gradually succumbed over the centuries to Assyrian empire-building. It's not the main focus of the book though.

<comment><USER5> Thank you! Since I heard about the Antikythera mechanism more ancient times have sparked an interest.

</comment></comment></comment></comment></comment></comment><comment><USER7> David Graeber has a nice way of explaining money arising from IOU's in Debt: the first 5,000 years. It makes a lot of sense and basically explains why the barter myth is so impractical that it could never have been a reality in any sizable community.

<comment><USER8> I liked his explanation of state-controlled currency evolving as a technology of war. I.e. the king needs to pay his soldiers something portable, dense with value, and hard to counterfeit, and precious metal coins fit those requirements. And then to guarantee that the coins are accepted for payment and hold their value, he imposes taxes that have to be paid by everyone using those coins. Pretty elegant and a system that, even as as a taxpayer, I hadn't thought carefully about.

<comment><USER9> Yes, the idea that taxes and debt existed before money to grant that money value was very eye opening, and an obvious model in hindsight.

Another example of someone in power saying "Hey, see this problem we created? Well, we also have the solution..."

<comment><USER6> Taxes certainly existed before state-issued currency, but the purpose was obviously not to grant value to the currency. (It can't have been -- this was _before the currency existed_.)

Ancient taxes were assessed in kind, most commonly in grain or labor. The reason was that the government wanted the grain or labor. The main benefit of taxing in metal is that grain is perishable and voluminous, not that it creates demand for more metal.

Consider a stylized section of Chinese history:

State-issued currency: copper coins (low value, accepted most places); paper notes (high value in the capital, hard to spend elsewhere)

Means of exchange: raw silver valued by weight

Form of taxation: silver

<comment><USER9> I was replying to the specific use case of creating a tax to grant value to a freshly invented currency by giving it to occupying soldiers as payment while requiring merchants to pay taxes using it. It was intended to speed up adoption because the merchants needed to get the coin for taxes so had to accept it as payment.

<comment><USER6> Do you know of such a tax? There are two types of freshly invented currencies:

1\. Currency invented where there were just raw materials before. ("Conceptual invention")

2\. Currency invented to replace or exist alongside other already-known currency.

In case 1, I believe the currency is generally an object that was already valuable, and therefore doesn't need support. Coins were usually able to trade a little _above_ their value as measured in raw material because of the nominal standardization they provided.

Case 2 is not at all rare, and there are even cases of states deciding to make coins from a worthless material (iron) for ideological reasons. Everyone can have iron.

This seems like an ideal case for propping up the (otherwise too low to bother with) value of the ideological coins, but I'm not really up on the history of this kind of thing. I know the iron-coin states were often economic failures (e.g. Sparta). I know there were a lot of difficulties with paper money in China, but I don't know the details.

<comment><USER9> "Fresh" from the perspective of a population might be more accurate to what I'm saying - not invented from nothing (that was inaccurate wording). The book we're discussing goes into a lot of detail on this, more than I could having read it so long ago now.

The wikipedia article briefly mentions this: [https://en.wikipedia.org/wiki/Debt:_The_First_5000_Years](https://en.wikipedia.org/wiki/Debt:_The_First_5000_Years)

"The author postulates the growth of a "military–coinage–slave complex" around this time. These were enforced by mercenary armies that looted cities and cut human beings from their social context to work as slaves in Greece, Rome, and elsewhere. The extreme violence of the period marked by the rise of great empires in China, India, and the Mediterranean was, in this way, connected with the advent of large-scale slavery and the use of coins to pay soldiers. This was combined with obligations to pay taxes in currency: The obligation to pay taxes with money required people to engage in monetary transactions, often with very disadvantageous terms of trade. This typically increased debt and slavery."

It occurred mostly in subjugated nations as a way to bring in the new money (from the perspective of the conquered, who saw no value in this foreign coin). It accelerated adoption in populations who had no familiarity with the system, and indeed may have been operating on non-monetary systems still (the book credits Alexander as wiping away many of the last vestiges of such economies).

Looking at the above passage, it has some resemblance to company scrip.

<comment><USER6> > "The author postulates the growth of a "military–coinage–slave complex" > around this time.

I'm trying to get a sense of where to put this on a continuum between "I could imagine things happening this way" and "here are contemporary records in which the king specifically states that the new tax is needed in order to get people to accept the new coins".

Postulation isn't really what I'm usually looking for in a historical work.

<comment><USER6> I should point out that historically, getting people to accept metal was not an issue that usually came up. For example, Hammurabi's code details a punishment for certain merchants who will accept metal as payment but refuse to accept grain. That's the king complaining that what merchants want is to accept metal _exclusively_ (though not coins; they are not known to have existed at the time).

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> The more interesting way to analyze history, rather than trying to evaluate the degree of barter, is to seek out the most saleable good which was in use at a given place and time. Humans must solve the problem of "coincidence of wants" (ie. You raise chickens and I'm a woodworker - do we always need each other's goods?). Naturally, they begin to use the most saleable good available to their community as "money" for trade. The most saleable good (the most marketable and easy to sell) is usually the good available to them which scores highest on the following five properties (imagine a radar chart): Divisibility, Durability, Portability, Fungibility, Scarcity.

This way of thinking can provide a satisfying explanation of the emergence of gold as a global store of value.

For more reading: [https://mises.org/library/origin-money-and-its- value](https://mises.org/library/origin-money-and-its-value)

<comment><USER11> The coincidence of wants is likely a myth.

Humans operate by doing each other favours. You'll find you intuitively know who you've done a favour for and who you owe a favour to. It's inherent to being humans and three year olds can do it - as science has discovered.([https://www.en.uni- muenchen.de/news/newsarchiv/2016/paulus_s...](https://www.en.uni- muenchen.de/news/newsarchiv/2016/paulus_socialcapital.html)) We all walk around with a favour ledger in our heads.

Essentially "here's a chicken, you owe my a chicken's worth of something sometime".

As groups get larger you end up taking tokens as an IOU aide-memoir. And to nail those who try to cheat.

That then evolves into money. Token money. Tokens representing promises.

<comment><USER12> _> The coincidence of wants is likely a myth.

Humans operate by doing each other favours._

But intuitive tracking of who owes you favors and who you owe favors to does not scale. The double coincidence of wants problem is not a myth; it just doesn't come into play until you start dealing economically with groups that are too large for intuitive tracking of favors to work--roughly, groups larger than the typical hunter-gatherer tribe.

<comment><USER13> As we see in the comments above, the gift economy scaled to include Bronze-Age Mesopotamian international trade. It's true that a Hittite in Hatti wouldn't know everyone in Nineveh, or indeed anyone, but he knew the Hittite king, who knew the king in Nineveh.

</comment></comment></comment></comment><comment><USER14> This was a valuable read.

I think a similar misunderstanding takes place with Hobbes's idea that the man in the state of nature lived in a war of all against all. There's simply no evidence that this ever happened, even though it has been used by Hobbes and others as a justification for the need of oppressive institutions.

I think that if we start investigating the conceptual underpinnings of things quite a bit of economical and political thought will prove to be essentially unfounded and unscientific.

This being said, we can't entirely fault people like Hobbes and Smith who didn't have access to the investigative tools that are now available. We can however fault today's social scientists who continue to build on faulty foundations instead of honestly reassessing their theories.

<comment><USER15> To over-simplify, Hobbes' "man in a state of war" is a noble or land-owner, who needs to keep control of his property against the landless peasantry and opposing nobles.

This is reminiscent of how, say, in Athenian democracy, a citizen was a male property owner - and most of the population just didn't count; most people were reduced to slavery (much due to debt actually!). Some of this conception persisted all the way up to the original US constitution - women don't count, slaves don't count but are property etc.

As for faulting Hobbes - you can fault him plenty. There was critical anti- establishment practice and thought, always - in varying forms.

</comment></comment><comment><USER16> Not sure whether the expansion of this 'psychological debt model' is desirable. Because it's impossible to quantify such debts without money, it becomes more difficult to optimize allocation. Maybe the people in the woods haven't found water during many days. Suppose I have some water. More than I'd need for now, but not enough to last for years. I would not be inclined to give any to them. Sure, the woods people might make me a meal or sing for me which is nice, but my water supply is ultimately a guarantee for my long term survival. But if they did have even the concept of money, they might offer a high price, a price that allows me to say 'hey, with these resources i could build a house/attract a partner/drive away in a lambo and that's more useful to me than one month out of my seven months of water'. The antropologies make a compelling case for a different precursor to money and these gift economies are very similar to a money based economy. But money does offer the additional benefit of value quantification and security of deposits.

<comment><USER17> If the woods people have been without water for days, and you deny them water, they are probably going to kill you and take your water. Remember, your first priority when encountering other humans is to survive, sometimes the right gift may save your life.

<comment><USER16> I wasn't very specific about the situation. You are right in the sense that trade makes sense only among equals, the rest would just be forced to give up their possesions. So we have to assume this isn't possible. We can assume I am standing on a cliff they can't easily reach. Or perhaps I have a few muscular non-thirsty buddies with me.

<comment><USER17> Even if you are equal in strength, they may choose to fight you out of desperation, giving up some water is probably still preferable to the risk of a fight.

</comment></comment></comment></comment><comment><USER18> There was a great blog post I saw some years ago on HN about someone reminiscing about halloween candy trading as a kid. They remembered fondly about just how organized the trading quickly became. it was all barter, but there emerged quickly a candy franca. All the kids were willing to accept three muskateers bars because they knew others would accept them, and worst case they were at least tolerable to eat.

While I agree that the barter economy as a rhetorical construct is most certainly made up, being very useful in freshman econ, I'm not convinced it money could possibly happen without first having trade in general. I would argue that money happens very quickly, which is why you're not going to see a lot of evidence of extensive barter. If one childhood is enough to establish a candy currency, then you'd expect a similar currency to develop very quickly in any society.

<comment><USER19> The argument from the apparent source of this (Graeber's _Debt_ ) is that the progression of "barter, but that's inefficient so we create -> money, and then later we create -> debt" is historically inaccurate—instead, debt comes first, barter also but mostly for dealing with strangers, and then money is a later invention that has to do with sophisticated (relative to what came before) military logistics in large states/empires.

This is an oversimplification but gives you the gist of the book's argument. So yes, it agrees that money is a relatively late development and trade existed before it and was largely barter-based _but only when strangers or rival groups traded_ , but the central argument is that debt (basically) came _first_ rather than _last_ , and effectively precedes money, which is more a tool of debt than debt is a tool of money, if you will.

<comment><USER20> Was it "formal" debt though, or more like "I'll give you some of my extra grain, because you seem kinda friendly, and you might repay me the favor if I happen to be in trouble in the future"?

<comment><USER19> Things like tally sticks for tracking debt were used, absent and before currency, it seems. Pretty widely. IIRC (it's been a while since I read _Debt_ ) the book asserts that very small tribal or family economies likely worked the way you describe, with informal, mental tallies of debts, and as communities got just a bit larger physical tallies took over, persisting for some time. A consequence of this is that debt isn't surely "less real" or less essential/natural than money, nor even newer, but in fact _more_ real, _more_ essential or natural (so to speak), _and_ older.

<comment><USER21> Even in small groups you still need a currency (unit of account) before you can keep a tally, though—unless you're going to keep separate tallies for each kind of good, which quickly becomes impractical since even similar kinds of goods may not have equal value. Also, you need some standard good with broad marketability as a means of settling debts which can't be paid in kind (i.e. legal tender or equivalent).

<comment><USER22> They certainly had a unit of account (bushels of grain, for example) to quantify debt, but they didn't have a currency, which has additional necessary criteria besides unit of account.

What these cultures had, according to Graeber, were essentially ledgers for keeping track of debt.

</comment></comment></comment></comment></comment></comment><comment><USER23> At some point the article states that money "might just be a choice", but I think the article itself is pointing to the evidence it is not.

The git economy in a village and the one in a community of friends have something in common. Another hint is yet in the article when it states "it's hard to imagine a gift economy working to build skyscrapers and iPhones".

It seems pretty clear to me that the problem of a gift economy is that it doesn't scale.

As long as every person in a group knows each other it is fairly easy to keep track of gifts given and received. This becomes impossible as the group grows and the number of people each person has to keep track of grows with O(n).

Of course you can divide a big number of people into groups and have those groups use a gift economy between them by having leaders keeping track of gifts given and received between groups.

And of course can also have multiple levels of subdivision. But the problem becomes clear. The system is quite centralized and there is no direct way for someone in one of those groups to exchange goods and services directly with someone of another one without the good or service going up the command chain and down to the other side.

<comment><USER24> It sounds like you're criticising barter rather than a gift economy.

Unlike in barter, in a gift economy no one keeps track of who owes what to whom, they just all give each other what they need.

To give an example, I've long participated in the open source community, where I give away software that I've written and help others on IRC, in various forums, and on stackexchange. I don't ask for or expect anything in return, but I know I'm helping the community and I seek and accept aid from the community when I need it, by asking my own questions and using software freely given away by others.

This example is of a well functioning gift economy which has scaled incredibly well.

<comment><USER25> > Unlike in barter, in a gift economy no one keeps track of who owes what to > whom

My reading of gift economies is that there often is some element reciprocity. In any given context, there might not be a direct exchange of gifts, but those not participating in the process over time get excluded from future gifting. And there are all sorts of "social status" and signaling effects that make this much more than just altruism.

</comment></comment></comment><comment><USER26> in 199x in Russia the B2B economy was working basically on barter. The accounting/business software support for 5-10 segment length chains of "mutual credit" ("vzaimozachet") involving multiple business partners between your product and finally money (or something almost as liquid as money) was a feat of business software engineering separating leaders from the chaff - while the world line of a given barter chain may have been crossing spacelike/timelike boundary several times it still had to look correctly in all accounting frames of reference :)

One of the things which emerged to be almost as good as money back then was "energy credits" with large power plants and networks serving as a kind of banks/clearing houses.

<comment><USER27> This sounds absolutely fascinating.

Do you have any links that go into more detail about the Russian B2B bartering and accounting?

<comment><USER26> not really, i'm 22 years out of that game. While most related info on web is in Russian, googling something like "russia multilateral mutual offset barter 1996" (any 199x year works to filter out links talking about modern situation) seems to bring links describing various facets of how it was back then.

</comment></comment></comment><comment><USER28> Is this article just rehashing a chapter from "The Debt, first 5000 years"?

<comment><USER29> More or less. Graeber is cited.

</comment></comment><comment><USER30> The relationship between monies and goods has been murky. But it's kinda cool to cut a clear line to say that bartering economy exists before money. But I think they always co-exist. This relationship is more like chicken and egg.

I did some research on how gold became money. Archeologists found evidence of gold usage dated 40,000 BC. When gold shows up in written history around 10,000 BC, it's already money. We did not really know if gold was good first or money first. I conclude that it's a little bit of both when humans first found it. I wrote about the topic in this article:

[https://bitflate.org/post/2019/11/29/how-gold-became- money.h...](https://bitflate.org/post/2019/11/29/how-gold-became-money.html)

Going back further, I think we can say sex was the first kind of currency. Organisms exchange sex to reproduce.

Today, we have Bitcoin. It's also unclear how we should define it: asset or money. The answer is it's a little bit of both. I hope the IRS will lower the tax rate on Bitcoin when they understand this.

</comment><comment><USER31> Money is just a representation of the debt incurred in a "gift" economy (a "debt" economy would be a better term for it) and allows the extension of those practices to strangers or people you don't trust or can't have some influence over. Gift economies still exist today in Western countries, often in rural areas among neighbors where you will do a favor, help out, or lend an item in exchange for likewise help at a later date. This works well in small groups that know each other well but breaks down when it becomes hard to track who did what for whom. Hence the invention of a tally system like money.

</comment><comment><USER15> I read about this anthropological/historical fact in David Graeber's excellent "Debt: The First 5000 Years", mentioned in the article. More about that book:

[https://en.wikipedia.org/wiki/Debt%3A_The_First_5000_Years](https://en.wikipedia.org/wiki/Debt%3A_The_First_5000_Years)

or you can just download it. How's that fir a gift economy? :-)

[https://libcom.org/files/__Debt__The_First_5_000_Years.pdf](https://libcom.org/files/__Debt__The_First_5_000_Years.pdf)

</comment><comment><USER32> I find Nick Szabo's argument that money-like collectibles were in fact the key technological advantage Homo Sapiens had over Homo Neanderthalensis an intriguing one:

[http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CD...](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/shell.html)

It's safe to say that something-like-money is substantially older than agriculture.

<comment><USER33> This article makes the same mistakes that the OP's article does - assumes the truth of the myth of barter. It even uses the odd term 'time-offset barter', which I have never seen outside of libertarian/ancap analyses. Barter is a spot transfer, 'time offset barter' isn't barter but something else.

<comment><USER32> I'm quite sure you didn't read the article, which does no such thing.

<comment><USER33> From the article:

 _Barter requires a coincidence of interests. Alice grows some pecans and wants some apples; Bob grows apples and want some pecans. They just happen to have their orchards near each other, and Alice just happens to trust Bob enough to wait between pecan harvest time and apple harvest time. Assuming all these conditions are met, barter works pretty well. But if Alice was growing oranges, even if Bob wanted oranges as well as pecans, they 'd be out of luck -- oranges and apples don 't both grow well in the same climate. If Alice and Bob didn't trust each other, and couldn't find a third party to be a middleman [L94] or enforce a contract, they'd also be out of luck._

This is the canonical Myth of Barter, where some society is assumed to have existed that was so inconvenienced by the double coincidence of interests/wants/needs that it invented money. This never happened as there exists no evidence that a society existed that used barter as its main method of exchange; barter was used on the edges of society, spot transfers made between people who did not have the trust necessary to support debts.

Here's the passage where he refers to 'time-lagged barter':

 _Local but extremely valuable trade was, this essay argues, made possible among many cultures by the advent of collectibles, by the time of the Upper Paleolithic. Collectibles substituted for otherwise necessary but non-existent trusting long term relationships. If there had existed a high degree of sustained interaction and trust between tribes, or individuals of different tribes, so that they gave each other unsecured credit, this would have stimulated time-lagged barter trade._

I did read the article. In fact, I read this article years ago shortly after it was published as back then I was an anarcho-capitalist, very interested in non-state solutions to money.

<comment><USER32> That's just a straightforward description of what barter is. Barter exists, it has the indicated limitations.

Szabo's argument is that collectibles predate history by tens of thousands of years, that rather than replacing some mythical bartering system, that a system of exchanged collectibles co-evolved with the entire concept of trade.

 _substituted for otherwise necessary but non-existent trusting long term relationships_ , as in, allowed them to exist in the first place, not replacing some barter-only system. Nick isn't crediting the Austrian origin mythos here, he's providing a cogent alternative to it.

What I'm seeing no evidence for, and don't expect to, is the claim that _debt_ precedes collectible money. This is quite unlikely, as it seems to be a feature of sedentary agrarian cultures; it's difficult to picture it arising in a milieu of traveling bands of hunter-gatherers, who are mutually suspicious, often rivalrous, and may not speak the same language.

</comment></comment></comment></comment></comment><comment><USER34> All marriages in ancient kingdoms were barters.

It still exists today as 'giving away' of the bride. The female's dna and germline gets the best it can buy with dowries and the bride's attributes.

</comment><comment><USER35> In games, even when the game is explicitly designed not to have currency, players will invent one in order to facilitate trade. It'd be strange if humans didn't do this in real life too.

<comment><USER36> Sure. But we are aware of the concept.

It would be interesting to see this emerge in a population unaware or unexposed to the concept of money.

<comment><USER37> I imagine this has been studied to some extent in various uncontacted tribes. Does anyone have any information on that?

<comment><USER38> The first chapter in "Debt: the first 5000 years" deals with the issue.

</comment></comment></comment></comment><comment><USER39> Interesting that they mentioned The Rainbow Gathering as an example gift economy, rather than Burning man which is 7x larger and I would guess more widely known.

<comment><USER24> Is Burning Man really a gift economy when it costs many hundreds of dollars to get in?

It's more like an expensive theme park.

<comment><USER40> Inside, it is mostly a gift economy. Selling and barter are prohibited, except for ice and coffee sold by BMorg at Center Camp. There is some covert selling of drugs, but those are also largely gifted. It generally works because most people bring too much stuff anyway.

</comment></comment></comment><comment><USER41> No mention of _potlatch_.

> A potlatch is a gift-giving feast practiced by indigenous peoples of the > Pacific Northwest Coast of Canada and the United States,[1] among whom it is > traditionally the primary governmental institution, legislative body, and > economic system.

[https://en.wikipedia.org/wiki/Potlatch](https://en.wikipedia.org/wiki/Potlatch)

\- - - -

I have a crude "theory" that economic forms follow density:

Small groups, families and small clans, operate more-or-less communally (not political Communism; I mean communal living. Sharing resources, etc.)

Larger groups, tribes and neighborhoods, operate more-or-less on barter or favor-balancing.

Beyond that, you get money evolving out of long-distance trade, and modern mercantile and financial (as contrasted with "just" economic) systems.

</comment><comment><USER42> It was a good article until the gift economy crap at the end. Game theory explains all of this quite well.

Money is desirable because it makes transactions and economic calculation so much easier. As a pure abstraction, money is simply a ledger ([https://www.minneapolisfed.org/research/sr/sr218.pdf](https://www.minneapolisfed.org/research/sr/sr218.pdf)). When humans live in small groups related by blood, they just keep the ledger in their heads (if at all) because the penalty of cheating is so great that no one will defect (exile from the tribe and a lonely death).

When humans need to transact with people and there is uncertainty about (a) whether they will be able to punish cheating, and (b) whether they will ever meet this trading partner again, then they will use a more explicit and trustworthy form of money to reduce the risks. For most of human history the only real option here was some kind of physical token, which had to approximate the ledger abstraction: uniform in quality, easily divisible, easy to authenticate, with as inelastic a supply as possible.

The modern sovereign state allows for fiat money, since the state can simply declare that its official currency is the ledger that everyone will use. It's quite efficient, since you can do things like maintain a banking system that exists primarily as numbers in a spreadsheet rather than vaults full of dusty gold bars. Our fractional reserve system also mingle debt and money, and for most of us the two are equivalent.

This makes perfect sense when you consider that money is a claim on the future output of everyone who agrees to use the money. It's an EOU: everyone owes you. Thus, if you issue fiat currency against public debt, it's effectively an EOU as well since everyone in the economy is indirectly responsible for the eventual repayment of that debt. Of course, sovereign currencies have borders, so looking at the ledger used by governments to keep score amongst themselves is quite telling.

However, when there is no socially accepted authority to dictate consensus, how do mutually disinterested individuals agree on a form of money? This was a pure thought experiment until the invention of Bitcoin, because the options were exceptionally limited: precious metals were so much better than anything else that had been tried, for reasons I won't go into here, that there really wasn't a choice. But with Bitcoin, you have a protocol for digital cash that can be used to create an infinite number of ledgers with the same desirable properties. How do we choose which one to use?

The answer, of course, is proof-of-work.

<comment><USER43> Given Bitcoin has failed miserably as a currency, being almost universally abandoned for this purpose for various reasons, I don't see how you can present it as the future of money.

Also, game theory is a very limited model of human behavior. That you choose to invoke it, and you choose to believe that humans are simple rational game- theoretic "players" is not in any way proof that they actually are any of these. There is a lot of observable human behavior which contradicts rational and game-theoretic models - just look at some observations from behavioral economics.

<comment><USER10> We learned this lesson in 2016 during the Bitcoin scaling wars. The path to global unit of account does not begin with "medium of exchange" it begins with "store of value".

The primary purpose of Bitcoin is to be a store of value (the definition of money), without this achievement it cannot evolve to a medium of exchange (definition of currency).

<comment><USER44> "Store of value" is not how economists (and most normal people) define money. Pretty much any non-degrading asset can be a store of value. That doesn't make them money.

To be money, something must fulfill three criteria: 1) be a medium of exchange, 2) be a store of value and 3) act as a unit of account. It helps if the something is also fungible, easily divisible, etc.

<comment><USER45> Missing the forest for the trees. Those three functions of money are the "cliff notes" description of money, but there is a deeper abstraction that all of those properties can be derived from: money is a ledger. In the case of cash or bitcoin, the ledger has a constraint that negative balances are not allowed.

</comment></comment></comment></comment></comment><comment><USER46> Author seems ignorant of [http://icm.clsbe.lisboa.ucp.pt/docentes/url/jcn/ie2/0POWCamp...](http://icm.clsbe.lisboa.ucp.pt/docentes/url/jcn/ie2/0POWCamp.pdf)

<comment><USER47> That is largely in line with what Graeber's book says, in that most of the use we see of barter being out of necessity by _people who already know how, and were familiar with using money_ (say, after their money-using civilisation collapsed), not as much before monetary systems existed (except for some trading between tribes).

And then later you have one of their institutions basically becoming a central bank and issuing a currency!

</comment></comment><comment><USER48> A similar kind of a "delayed barter" economy did exist until recently in communist Bulgaria. Without any intervention from the government, people were exchanging items and doing mutual personal favours (sometimes against the law), all based on one's "social network".

Knowing the shopkeeper in the butchery meant that he could reserve the fresh meat for you once it gets delivered, while you, for example, as a car repair guy in a state enterprise would provide him with some parts for his Lada from any leftover quantities. It was a hidden parallel economy that was "boosting" the planned economy. No kind of accounting was taking place between the exchanging parties, people were doing it for their own interest in the long run.

These types of relations between people were (and still are) leading to many corrupt practices. A police officer or any kind of state representative would treat you differently if you were a part of their social circles. It's a toxic environment where you start putting greater value on connections rather than on actual work and self-development.

<comment><USER33> Barter is a spot transfer. 'time offset barter' or 'delayed barter' isn't barter, and I've only seen this weird term used in libertarian/ancap/Austrian economists attempting to come to grips with the rather strong evidence against the myth of barter from which they derive their theories of money.

</comment></comment><comment><USER49> "On paper, this sounds a bit like delayed barter, but it bears some significant differences."

Yeah sorry, but it is a barter economy. They only frame it differently to get their papers published.

Yes, it may work not exactly like described in the economics textbooks (and gift economies have some interesting specific properties). But I am really tired of people claiming everything in economics textbooks is to be taken absolutely literal, and if the real world is not like that, then classical economics has been refuted.

Of course they use idealized models in the textbooks, including the rational actor. The economists are well aware that they are using simplified models.

<comment><USER50> That's not the same thing as bartering at all.

When you do a favor for a friend (like giving a referral for a job), do you see it as a transaction where you expect them to pay you back at some point?

<comment><USER51> >When you do a favor for a friend (like giving a referral for a job), do you see it as a transaction where you expect them to pay you back at some point?

To some limited degree.

If you were later in your life in need of a job, and your friend could refer you to their new company, but they refuse to because of arbitrary reasons.

Would you not think they are being a poor friend? Even more so because you did a very similar favor for them in the past?

<comment><USER52> Possibly, but some expectation of reciprocity does not equal debt and an 'internal ledger'. That some aspects of some human interactions can be modelled by a transaction model doesn't mean that they are inherently transactional. We may well find that there are important differences and that the actual internal human model is different.

Even your example only really works because you have constructed it in a specific way. Of course if your friend could do you a small favor that helps you greatly, and that you have performed for them in the past, you would expect that they owe it to you, as if you had a mental ledger. However, if the situation is slightly different, say, their father is ill and they are caring for them in hospital, would you still expect them to call their office to recommend you? If they were out of a job at the moment as well, but happened to have some extra money, would you expect them to provide you a loan so you could fund a start-up instead of getting a job?

I don't believe human relationships and gift economies reduce to a kind of barter. There are barter-like aspects to it, but I think they stem from different internal impulses. I may well be wrong, but I don't think we can assume they are not simply because some mutual exchange is taking place.

<comment><USER49> Again, economic theories don't need to be taken literal, they are simplified models. Just because somebody helps somebody else in need without immediately expecting a carrot in return, doesn't mean bartering is refuted.

Even in our today's world with money, people help other people in need. I don't think it defies economic reason, either. It is "pay it forward" or a kind of social insurance, as people can expect the same being done for them. Also perhaps it is simply a different kind of interaction, who says EVERYTHING has to be modeled as a trade? Or maybe it is the price for belonging to society, or to a certain circle of people, who would shun you if you would display antisocial behavior. Not every exchange good has to be a carrot.

Maybe the insurance model explains it quite well, now that I think about it.

Rational actors also work out in the long run, because by evolution the more rational strategy prevails. So people may not be aware why they help others (they don't do a calculation in their head every time), but it can still be the rational thing to do.

</comment></comment></comment></comment></comment><comment><USER53> The historical informations on the non-existence of barter economies was interesting, but then the article went into a nosedive with an anarcho- anticapitalist rant on the evils of money.

<comment><USER54> > nosedive with an anarcho-anticapitalist rant on the evils of money

This seems like a disproportional emotional response, considering that the article was roughly 30 paragraphs, out of which 1 was dedicated to "the evils of money" and 1 to the current existing anarchistic communities.

I dont really care, but you might gain from understanding your own bias in this regard

<comment><USER53> What I wrote might have used too strong words, but I feel like all the discussion around not-barter economy was just used to support the point the writer was doing on the evils of debts and money.

</comment></comment></comment><comment><USER55> While this is a thought provoking article, it makes assumptions that are not necessarily true. If a person thinks in terms of resources and not in terms of products you can begin to see the fallacies. It is easy for a group with common interests to share resources. The problems begin to arise when the group doesn't have a resource that it needs. As an example, if the Iroquois lived in a region where there was no obsidian which they would want for making tools and hunting instruments, they would need to approach a neighboring community that has access to the material If that community didn't want the Iroquois to have that material because it would upset the balance of power in that this material could also be used for making weapons of war. If the other community already had all the resources it needed to comfortably survive, how would the Iroquois over come their reluctance to give them obsidian? For the Iroquois this is becoming a matter of survival of their people. It they don't have this resource they won't have the tools they need to farm or to hunt. This is just a simple example, with more complex societies the more complex the problems. In my life time, I have seen people try to sustain "gift economies". I remember the communes of the sixties. On paper they sounded quite reasonable. Most of them didn't survive or evolved into capitalistic economies. One last point. Slavery was not an out come of the invention of money. It was the out come of the invention of war. What do you do with enemy combatants that surrender? Do you just kill them? Not if your humane. You make them slaves.

<comment><USER56> Commune's are unstable, but can work fine when separate from income streams. I am aware of one that lasted 30+ years slowly dissolving as no effort was made to add new members and people slowly left or died over time.

Monastery's demonstrates what it takes for such communities to last over hundreds of years. Effectively they must recruit, be economically viable, and avoid any single point of failure like having a specific leader.

<comment><USER55> Monastery's receive resources from the Church.

<comment><USER56> Donations from the public or formal religious institutions are just one revenue source. Often they where effectively self sufficient gathering revenue from farming, winemaking, baking etc. My point was outlays need to be less than revenue for the institutions to survive long term.

The downfall of the self sufficient commune movement is it frequently resulted in poverty. The example I am referring to had well paid professionals including doctors etc who saved money by joining. Low rent including utilities, food, appliances, and household supplies allowed members to travel and party more. In effect a collage fraternity without the collage rather than a monastery without a religion.

<comment><USER55> My point was is that they participated in a larger economy.

</comment></comment></comment></comment></comment><comment><USER57> As Smith described, people didn't invent money straight away. First, resources like salt and metals; then stuff you can melt (easily divisible). Then official coins of equal weight to fight counterfeiting and inaccuracy of weight.

I'm afraid this is one of the "history doesn't fit my ideology" pieces.

<comment><USER58> What? Smith? As in Adam Smith the guy who died in the year 1790?

I'm not a historian but I'm pretty sure his ideas about history aren't relevant to us in the year 2020.

<comment><USER59> Might want to read the article first.

The first two words after the title are "Adam Smith". Later text confirms that it's the same person, with "The man who arguably founded modern economic theory, the 18th-century Scottish philosopher Adam Smith, popularized the idea that barter was a precursor to money."

</comment></comment></comment><comment><USER60> If barter never existed, then how did Christopher Columbus and his many successors through out ages trade with natives in America or Indonesia? They definitely weren't using IOUs.

there's already very good rebuttal to David Graeber claims by Robert P. Murphy [1]: "Finally, we have actual case studies of communities developing money prices from scratch: namely, prisoners who end up using cigarettes as the common medium of exchange. The classic work here is Radford's 1945 article, "The Economic Organization of a P.O.W. Camp." There is nothing in Radford's account that conflicts with the standard economists' story about the origin of money. The prisoners certainly weren't giving each other things from their Red Cross kits as gifts or as loans. No, they first were trading (in a state of direct exchange) and cigarettes quickly became the money in their community for all of the reasons that economists typically cite.

And to reinforce the point we made earlier, Radford explains that the prices (quoted in cigarettes) of various items were posted on a board. If Graeber and his colleagues stumbled upon the ruins of this P.O.W. camp, they would presumably conclude that there was never a preexisting state of barter, because they only found boards listing prices quoted in terms of cigarettes. There were no boards listing the thousands of pairwise permutations of direct- exchange ratios, and so clearly the Mengerian story must have been wrong — so would go the erroneous reasoning of Graeber."

[1] [https://mises.org/library/have-anthropologists-overturned- me...](https://mises.org/library/have-anthropologists-overturned-menger)

<comment><USER61> > Trade did occur in non-monetary societies, but not among fellow villagers. > Instead, it was used almost exclusively with strangers, or even enemies, > where it was often accompanied by complex rituals involving trade, dance, > feasting, mock fighting, or sex—and sometimes all of them intertwined.

They talk about that and say barter generally did exist as trade between groups outside the local community. Which makes sense as an alternative to the gift economy.

Also POW camps aren't really great examples because they're a) already coming from money based societies b) not producing their own goods, ie all incoming things are basically gifts especially in the POW camp and everyone has a similar set of goods initially and c) they're in confinement which distorts any group's dynamics.

That last part of b is really because people all share 90% of the same set of resources and the main difference is the relative weights each person assigns to each item.

<comment><USER62> Also, not to forget, prisoners tend to not trust each other all that much. Most people are not in prison because they are trustworthy..</comment></comment></comment>


Why the Navy Needs Disruption Now - <AUTHOR> https://steveblank.com/2016/07/29/why-the-navy-needs-disruption-now-part-2-of-2/ <comment><USER2> Former sub-sailor here: An important point is made:

 _For the Navy, a Horizon 3 conversation would not be about better carriers and aircraft. Instead it would focus on the core reasons the Navy deploys a carrier strike group: to show the flag for deterrence, or to control part of the sea to protect shipping, or to protect a Marine amphibious force, or to project offensive power against any adversary in well-defended areas._

Carriers are vulnerable and probably cannot be protected enough to survive an all out war. Too often the conversation gets side-tracked by this debate. However, carriers are very useful outside of war for projecting power and influence around the globe, so they are still very useful.

<comment><USER3> At what point did the appearance of military power diverge from actual military effectiveness? Guerilla warfare in the 18th century?

It seems like the modern militaries are probably already well aware of these two separate things, to the point where there are probably two different conversations about Horizon 1/2/3, one for projecting the appearance of power for diplomatic leverage, and the other for wartime efficacy.

<comment><USER4> Projecting power isn't just about appearance, it's about being able to use your military even in small conflicts to enforce your policy.

<comment><USER5> The biggest problem in recent decades seems to be the reticence to actually pull the gloves off and really fight a war. War is one of those things you have to actually do, and not dick around with, to be successful. All that artificial "Rules of Engagement" provide is a framework for the enemy to hide behind.

<comment><USER6> > The biggest problem in recent decades seems to be the reticence to actually > pull the gloves off and really fight a war.

I guess that's probably true if your objective is to wage war and kill.

If your objective is to prevent or minimize those things than it's probably not your biggest problem at all and is actually your biggest accomplishment.

<comment><USER5> If you aren't willing to actually fight a war, then maybe you shouldn't fuck around and waste people's lives on a half-hearted adventure.

<comment><USER6> So you're arguing that we should kill _more_ people to save people?

<comment><USER5> That is not in any way what I'm proposing.

I'm saying that if you're going to fight a war in Vietnam, you should land the Marines at Haiphong and capture Hanoi, rather than idle away ten years and tens of thousands of American lives on a failed adventure, not to mention the hundreds of thousands of Vietnamese, Laotians, and Cambodians that died along the way.

If you're going to topple the government of a middle eastern country, you need to actually stick out the occupation and build a structure that will stand on it's own, rather than descending into anarchy when you pull out. If you're not willing to invest in that, then perhaps you shouldn't invest in the initial "Shock and Awe" portion of the campaign.

Moreover, 3000 years of history should be enough to convince anyone that invading Afghanistan is a terrible idea, maybe one step down from "launch an invasion of Russia in late summer."

<comment><USER7> US rules of engagement were partially to prevent Chinese intervention in the Vietnam War. The Chinese already had 100,000 advisors in the country in an anti-aircraft role and a full scale invasion of Hanoi by US Marines would have almost certainly resulted in a response by the PLA.

Even though the Chinese troops were poorly armed and poorly trained relative to US troops they had undergone some degree of moderization since the Korean War where they had fought the UN to a standstill. Given the logistical advantages of the Chinese to mass men and material (it was on their border vs half the world away) it isn't obvious the US would have prevailed in a escalated conflict. China was also a nuclear power by 1965 which was not true during the Korean War.

But I don't think any of this disagrees with the main point of your comment which is don't intervene where the rules of engagement prevent you from winning.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> You want disruption? Here are some ideas.

Build drone carriers. Who needs brave pilots in fighter seats when you can get the same results with slightly less brave drone operators? You can pack a lot more than 44 drones in each carrier.

Repurpose container ships. If Russians can launch cruise missiles directly from shipping containers (4 missiles per standard 40-feet container), the same can be done with drones. Imagine how much of them can be packed in 1000-container container ship, which looks like any other civilian cargo ship until the need arises.

Drone operators can control entire formations of combat drones (no need to actually fly these things — point and click interface should be enough with modern tech). Autonomous refueling, sensor fusion, battlespace mapping — the only need for humans in the loop is giving "go / no go" for kill requests.

Use large coordinated battlegroups with numerous uniform modular cheaper vessels instead of a few big expensive carriers surrounded by combat support. Every ship can (and should) be fitted with ECC and offensive electronic warfare options, which prevents attacking electronic support first. Try to jam 200 small ships simultaneously while they are constantly on the move in the large area — nearly impossible. No designated C&C ships — all battlegroup members can take multiple roles as needed, including command and control.

Fail-deadly "nuclear options" — if battlegroup communications are jammed beyond repair, drones can be programmed to proceed with their missions fully autonomously, until kill switch signal arrives. Looks harsh, but better than actual nuclear option.

Etc etc.

<comment><USER9> These aren't disruptive ideas, they're just bad ideas.

> _Build drone carriers._

You mean like regular carriers will be with N-UCLASS ([https://en.wikipedia.org/wiki/Northrop_Grumman_X-47B](https://en.wikipedia.org/wiki/Northrop_Grumman_X-47B)) or the optionally-manned F/A-XX ([https://en.wikipedia.org/wiki/F/A-XX_Program](https://en.wikipedia.org/wiki/F/A-XX_Program))?

> _looks like any other civilian cargo ship until the need arises._

This is called Perfidy. It's a war crime. [https://en.wikipedia.org/wiki/Perfidy](https://en.wikipedia.org/wiki/Perfidy)

> _Drone operators can control entire formations of combat drones_

They have a hard enough time controlling _one_ \-- bandwidth requirements and ensuring reliable communication are _hard_.

> _point and click interface should be enough with modern tech_

Right up until your adversary degrades your access to all that _modern tech_. Military tech needs to be _literally_ bullet-proof.

> _programmed to proceed with their missions fully autonomously_

The UN disagrees. [https://www.theguardian.com/science/2015/apr/09/un-urged- to-...](https://www.theguardian.com/science/2015/apr/09/un-urged-to-ban- killer-robots-before-they-can-be-developed)

<comment><USER10> > This is called Perfidy. It's a war crime. > [https://en.wikipedia.org/wiki/Perfidy](https://en.wikipedia.org/wiki/Perfidy)

Maybe, but it looks like a bit of a grey area. The WP article you link states that "Ruses of war are not prohibited", and [https://en.wikipedia.org/wiki/Ruse_de_guerre](https://en.wikipedia.org/wiki/Ruse_de_guerre) includes this:

 _disguising a warship to appear to be a neutral merchant vessel, or a merchant vessel on your opponent 's side, has traditionally been considered a legitimate ruse de guerre, provided the belligerent raises their own flag to break the deception, prior to firing their guns. This was called sailing under false colors. Both sides during the world wars used this tactic, most famously the Royal Navy's Q ships._

and also this:

 _German commando Otto Skorzeny led his troops wearing American uniforms to infiltrate American lines in Operation Greif during the Battle of the Bulge. Skorzeny later reported that he was told by experts in military law that wearing American uniforms was a defensible ruse de guerre, provided his troops took off their American uniforms, and put on German uniforms, prior to firing their weapons. Skorzeny was acquitted by a United States military court in Dachau in 1947, after his defense counsel argued that the "wearing of American uniforms was a legitimate ruse of war for espionage and sabotage" as described by The New York Times._

<comment><USER9> It would be different to design our fleet to "sail under false colors" during peacetime; and the US would be reticent about launching a fleet of ships that make civilian ships into targets. We don't have to rely on ruse to project power -- even if our carriers are vulnerable.

<comment><USER11> If it is an American ship flying American colors it is not sailing under false colors. Also, civilian merchants of the belligerents have been legitimate targets of the enemy since the dawn of naval warfare. Whether or not they are armed is irrelevant.

<comment><USER5> Most American merchant vessels are not American-flagged... Liberia, I believe, is the most common flag for US shipping.

</comment></comment></comment></comment></comment></comment><comment><USER12> After manually magnifying the size by 8x :-) that is a pretty good overview of the defense department strategy for developing the warfighting capabilities. It also demonstrates why you start every war with equipment that would have been great for the last one but sucks for this one. The thing about war is that innovation is tolerated because _people are dying_. It is sad but ultimately true. When there isn't anyone dying the tolerance for risk of failure is extremely low.

Even with that bias though things like rail guns and theater defense with lasers is continuing. If I were in a H-3 think tank I would be seriously thinking about what it means to have computers and sensors to be "free". Consider what it would mean if in addition to a tracer round in CIWS you fired a sensor round. A bullet with a cpu, a network, an a 9dof inertia sensor and one bit optical sensor. All sensor bullets in flight sending back telemetry about position and optical transits on their sensors above the horizon. Now your anti-ship missile has to be stealthy and invisible.

That is just off the cuff but such sets of sensors are cheaper to deploy than some of these bullets.

</comment><comment><USER13> For a better discussion of the future of aircraft carriers, see this Naval War College paper.[1] Especially the section on the various uses of carriers. They're vulnerable to an opponent with a major anti-ship missile capability, but most of the US's opponents don't have that.

[1] [https://www.usnwc.edu/getattachment/87bcd2ff-c7b6-4715-b2ed-...](https://www.usnwc.edu/getattachment/87bcd2ff-c7b6-4715-b2ed-05df6e416b3b/The- Future-of-Aircraft-Carriers)

</comment><comment><USER14> The article was a good analysis of both the down-and-dirty mission of an aircraft carrier, (i.e. actual combat, actual support), and the strategic, big-picture role of an aircraft carrier (e.g. force projection). So far so good.

But I was hopelessly lost when it tried to draw an analogue between the 'need for disruption' and the larger, big-picture view of why we have aircraft carriers in the first place.

Perhaps I'm misunderstanding the point, but I certainly _don 't_ want any sort of disruptive, mavericky thinking applied to how, why, when a Navy (any Navy, not just "ours") deploys force projection. This does not sound like an appealing recipe for responsible use of force and for limiting provocation of other parties to just below the level that they're willing to retaliate, and the like. So, in short, I don't understand the point the author's trying to make.

<comment><USER15> I believe you may have misunderstood the point. The author of the post suggests that why and when remain the same - to show the flag for deterrence, or to control part of the sea to protect shipping, or to protect a Marine amphibious force, or to project offensive power against any adversary in well- defended areas.

Today, the way we do this carrier strike groups. The author is arguing that the carrier strike model for achieving these goals is now ~50 years old. If you were to start today from a blank slate to achieve those goals, you'd construct something very different from a strike force. This is where he's suggesting mavericky thinking ought to be applied - in coming up with those blank slate solutions.

</comment></comment><comment><USER9> Let's talk _real_ disruption: money. DoD wastes money like you can't believe because they're _required_ to.

* Contracting takes _forever_ \-- actual times measured in months to years. We haven't had proper planning and budgeting from congress for almost a decade, so funds that expire are released late, forcing the services to take a bad deal signed quickly over a good deal that would come too late.

* No flexibility. Projects are funded as "Programs of Record" (or not at all) and funded for their life-cycle in the budget. Services fight endlessly to keep PoRs no matter how they turn out because it is so damn hard to start new programs.

* The system is designed to allow bad deals. It's legal (and not uncommon) for a prime contractor to subcontract work through a middle-man corporation that contracts back to a subsidiary of the prime to perform the work. DoD acquisition contracts include a negotiated profit fee with the prime, but often have no insight into the structure of their lower-level deals, allowing the primes to take a profit straight off the top, then an additional cut at the working level.

* All new acquisitions are driven "top-down" by resource sponsors distilling warfighter needs into "requirements" that are then solved with a materiel solution.

* We spend a lot of money on this stuff, and we can't make new programs, so we end up supporting things _long_ after their planned EOL. Check out B-52s, A-10s, F/A-18s, weapons, etc. It costs a lot of money to keep supporting this stuff.

* PoRs usually require a competitive tech development phase where you pay _two_ prime contractors to build solutions before doing a competitive down-select.

So... Make it easier to contract. Easier to spend small amounts of money to test solutions. PoRs should grow out of successful products, not the BS we do now. Be a bully in contract negotiations, and put some teeth in the regulations on contractors playing shell games. We don't see much innovation because the services can't move quickly, and they can't adapt to changing requirements.

How bout we disrupt _that_?

</comment><comment><USER16> Carriers are more of a psychological force projection than a physical one for adversaries such as China. No nation dare attack a carrier strike group because of the power behind the response if something were to happen. They are a "I'm not touching you" kind of a game at that level. A way for American to claim physical space for awhile and back up diplomatic rhetoric. I don't think anyone in the pentagon would be foolish enough to pit f/a 18s against modern missile defenses. For less well equipped armies they are used as a blunt instrument as in Syria, Iraq etc. Just so we're clear, only the most advanced countries have ASBM technology, it does not apply to many.

</comment><comment><USER17> The author seems to be forgetting that no two first-world, nuclear armed nations can ever engage eachother ever again without total mutual nuclear annihilation occuring. He spends the entire time worrying about highly advanced technologies that are only possessed in sufficient quantities by nuclear armed states. If that equipment were ever used, it would become pointless in a matter of hours once the nuclear weapons start flying.

With that in mind we ought to quit pouring all of our money on weapons designed for enemies that we can never realistically fight. It would make far more sense to retool for conflicts against insurgencies and developing nations.

<comment><USER18> That's been the thesis every since the Soviet Union detonated its first atomic bomb in 1949. It didn't stop Korea, Vietnam, Afghanistan, Iran/Iraq, or the two Persian Gulf wars from happening.

What seems to occur instead is that major powers fight via proxy wars, where they provide arms, training, covert assistance, and sometimes even open troop commitments on the soil of vassal states. This provides plausible deniability to the superpowers (neither of which _actually_ want to see the world end in nuclear annihilation); offloads the human cost of the war onto foreign, less- developed countries; offloads the political cost onto puppet governments that can be disposed of when no longer needed; and prevents widespread public discontent from threatening the ruling government.

Just because the war is likely to happen in the Persian Gulf or Sea of Japan doesn't mean that the weapons & tactics involved won't be developed by first- world nations.

<comment><USER17> >It didn't stop Korea, Vietnam, Afghanistan, Iran/Iraq, or the two Persian Gulf wars from happening.

So why do we need lasers, railguns, and stealth fighter jets to fight bands of rice farmers and goat herders?

<comment><USER18> Because those rice farmers and goat herders are armed with man-portable anti- aircraft missiles, explosives mines, assault weapons, and in a future conflict, likely lasers and railguns too.

<comment><USER17> If they were ill-equipped in Vietnam, ill-equipped in Iraq and Afghanistan, then why would potential combatants suddenly come into possession of weapon systems more expensive than their nation's GDP? World powers don't just hand out state of the art weapon systems all willy nilly, lest they end up falling to the enemy.

<comment><USER19> They were equipped by the Chinese during Vietnam, and they were very well equipped by the USA in Afghanistan (the original Russian invasion). Everything the Iraq army has ended up in the hands of various resistance and terrorist groups (including ISIS).

<comment><USER17> The article is about highly advanced anti-aircraft and anti-ship weapons. They don't even have armored infantry, let alone those.

<comment><USER18> It's a stretch to call them "ill-equipped" in Vietnam and Afghanistan, considering that the insurgents won both campaigns (with generous military assistance from the opposing superpower). No, they didn't have armored infantry - but they had surface-to-air missiles, anti-personnel mines, anti- tank missiles, and automatic submachine guns, all provided by the opposing superpower. The U.S. lost many aircraft against the North Vietnamese, and the Soviets lost many tanks and helicopters against the mujahideen in Afghanistan.

steve19 also makes the very good point that these weapons _did_ fall into the hands of the enemy: most of the Taliban were trained by the CIA, and the weapons our forces faced in Afghanistan were largely ones we had sold to the mujahideen in the 80s. Now the weapons left behind in Iraq are largely in the hands of ISIS.

The point of _this_ article is that the U.S. is likely to face similar asymmetric threats in any future war, where the opposition doesn't have the same weapons as us but they do have weapons that are very effective at countering us.</comment></comment></comment></comment></comment></comment></comment></comment>


Cognitive Biases in Software Development - <AUTHOR> http://smyachenkov.com/posts/cognitive-biases-software-development/ <comment><USER3> My personal observation (and view of course) is that most people simply cannot code. And I am not talking about that reverse-a-binary-tree or traverse-a- linked-list type of coding, but more profoundly they just cannot wrap their head around a problem and are able to create a _sufficient_ solution with respect to the context of the code and its environment at the same time. Good software development is strongly connected with ones ability to think clearly about any given problem and the ability to logically deconstruct it in smaller, more digestible thoughts. If there's confusion in the mind, there probably will be confusion in the code as well.

Also, it just seems as if many are unable to step back and look at the broader side of things when coding. Asking questions like: Are we using the right concepts here? Did we develop sufficient abstractions? Case in point: I was just refactoring a code base for a client where the code was paved with a `MemoryHolder` type, where simply `Buffer` would have been the better name for the same concept.

<comment><USER4> I don't think this is the right mental model of coding.

It seems a bit too similar to the idea that "most people simply cannot read".

We all accept that nobody can read without instruction, practice, and feedback. Why is coding somehow different? If anything, I think reading is _more_ foreign/difficult, because coding is explicit thinking, and we all think. Whereas reading is a completely synthetic act that starts with arbitrary symbols that must be memorized by rote before you can even take the next step of using them.

None of us start out life being literate, but few people lack the ability to become literate. Why is coding different?

<comment><USER5> _> None of us start out life being literate, but few people lack the ability to become literate. Why is coding different?_

To elaborate on the sibling comments, coding is _generative_ work instead of passive consumption like reading. This split becomes easier to see when looking at a bunch of domains.

Most of people can learn to _read_ a book but very few can _write_ a good book. Similarly, it's easier to _re-tell_ someone else's funny joke than be creative and write original comedy.

Many people can _learn_ basic physics equations like "f=ma" is "force equals mass times acceleration" but fewer are able to be _generative and discover_ new physics equations that are accepted by the science community.

Most people can listen to music and appreciate it, but a smaller percentage can play instruments. And then within the set of musicians, an even smaller percentage can _compose new original music._ There must be something more to it than "training and practice" to explain why a 19-year old Chopin can compose sophisticated piano compositions while most 70-year old professional concert pianists that have performed for _decades_ with more repertoire than Chopin have written no notable original music.

Coding may not be as hard as creating "Theory of General Relativity" but it's not the same as reading literacy.

<comment><USER6> Generative work is not all created equal. Most of programming we all do is like applying physics equations in practice. A tiny portion is truly on the cutting edge, more akin to physics research.

Likewise, a lot more emails and discussion comments and school reports are written, per volume, than masterpiece books.

<comment><USER7> I'd be willing to bet that

{people who can look at a real world problem, choose an appropriate physics model, and apply the right equations, correctly}

and

{people who can look at a real world problem, choose an appropriate logical model, and apply the right language/frameworks/code, correctly}

are probably really quite similar sets.

</comment></comment></comment></comment></comment><comment><USER8> There's also cognitive bias bias - prematurely jumping to the conclusion that some opinion is simply based on cognitive bias, and should _therefore_ be dismissed or contradicted. Basically, it's good to use awareness of cognitive bias to moderate your own thinking, but if you signal to others that you think they are labouring under some bias don't be surprised if they shut down the discussion ASAP.

<comment><USER9> I agree.

Criticizing someone for being biased is an ad hominem; dismissing their arguments because of it is committing the genetic fallacy.

In the extreme, it reminds me of this blog post, about how knowing about biases can let some folks universally dismiss others they disagree with (and thus manage to never learn or consider alternative ideas): [https://www.lesswrong.com/posts/AdYdLP2sRqPMoe8fb/knowing- ab...](https://www.lesswrong.com/posts/AdYdLP2sRqPMoe8fb/knowing-about-biases- can-hurt-people)

</comment></comment><comment><USER10> I work as a "consultant", building cloud based business software. Above all else, my job is to deliver value. Something I constantly struggle with is "clean code" vs just pumping out a mostly static transaction script and moving on.

More and more, I write code I'd almost be embarrassed for colleagues to review. But for the type of work I'm doing (poorly defined, highly volatile, potentially short lifespan), I can't justify anything more.

It doesn't feel good and it's still hard to accept that I'm doing the right thing.

If the language I'm working in supported FP, then my world would be much better.

<comment><USER11> I've been doing Go for a while now, and more and more I find myself just writing out really dumb looking code. Add a new line, write another short- lived variable, treat the guy reading it - me - like he's a complete idiot. I don't work in a team at the moment, but what I do now is the groundwork for something that will likely be used for the next decade (UI work, back / front- end).

<comment><USER12> > really dumb looking code

You cannot imagine how I'd value having really dumb looking code in my life.

Yet here I am, swimming in a swap of cleverness that I can't refactor nor will ever be able to wrap my head around.

I envy you.

<comment><USER13> Both "dumb" and abstracted code can be hard to read and change. The most important part is consistency.

It is generally easier to write dumb code that is consistent. It requires less mental energy and is often a very good starting point for refactoring into something more declarative and DRY.

The pain comes from inconsistent code, often either based on wrong previous assumptions, premature optimization or time pressure.

</comment></comment></comment></comment><comment><USER14> This is a good essay, and I think one of the main lessons is that programming is a small part of software development.

The question of whether to use an inefficient, readable implementation or an efficient, cryptic implementation can mostly be solved with the correct class topology. If classes are SOLID, then it is easier to justify a cryptic implementation of one method as that is hidden from most other developers. A class that will be inspected by others more, such as a business logic service layer, should lean towards inefficient, readable code.

Likewise, the question of whether to reuse or roll your own can also mostly be solved with a good architecture. Logically separating components makes it easier to tailor the implementation to the use case, and replace if necessary.

As always, breaking the problem into smaller problems is most of the battle.

Sadly software development as it is taught and measured by interviews, is mostly about programming and algorithms. The real art and value in software development is interface design and system architecture design.

</comment><comment><USER15> Personally I found that my productivity as a software developer was much higher when I was young and didn't think so much about the cleanest code or the perfect architecture for a problem and instead just tried different approaches. Now I often feel paralyzed by having to "get it right" from the beginning.

Valid (in my opinion) lessons I cherish today are keeping individual parts of a code base simple and understandable, documenting and testing a lot and preferring simpler solutions over complex ones.

<comment><USER16> This is exactly where in have ended up. And I am happier for it. My code is simpler and less "clever" per line but far wiser is structure and in use.

I abstract far more carefully now and I don't mind a few extra lines of code that make it easier to digest at a glance.

</comment></comment><comment><USER17> Over the past few years I have grown disillusioned by the seemingly hyper focus on clean code concept. It seems perfectly logical to have readable code. But the excess that we programmers do with the concept.

<comment><USER18> I think what's worse than that obsession, and perhaps is actually what you meant, is the concept of "elegant" code.

Elegant code is easily just as bad as spaghetti code. I can't even begin to quantify how many hours of my life were wasted because someone thought it was more important to make something elegant rather than understandable. I get that it's satisfying to make something that "makes sense" if you've built a mental model of the problem from the beginning, but if it's incomprehensible to others(without serious devotion to figuring out what is going on) then it might as well be crap in the first place. At least spaghetti code can be fairly easy to hack because there's usually lots of duplication and specialized code, making it straight forward to step through with a debugger and make a change without mysteriously borking the entire app. Elegant code, ironically, can be more flimsy because it's usually written assuming that the system stays perfect, and changes to the system reveal single points of failure.

Clean code can be written without necessarily going overboard with elegance to the point where it's not easy to understand. Even dirty code can be workable given documentation(can just be comments explaining what things do) and consistency.

<comment> UK-Al05 Clean code has always meant to simple, easy to understand, not elegant.

<comment><USER19> I don't think they are mutually exclusive.

In a recent interview question I was asked to find the largest three numbers in python list. My first attempt looped through the starting list, comparing the number to the previous minimum number in the result list - replacing the number if it was larger. I needed a get_minimum(function). It was the obvious solution that came to my head at thr time.

An hour later I realized a far more elegant solution was to sort the list and slice the last three elements. It felt far more elegant to me and was as easy to understand as the initial obvious solution that came into my head.

(Though this is why I dislike these type of interview questions. the first solution in an interview situation is not always the best or final one)

</comment></comment></comment></comment><comment><USER20> There's something deeply unnerving about ugly code, I don't think we can just say 'well it works'.

I think we should maybe aspire to find a frame of reference for evaluating when to change and not.

During development, I find iteration can be useful, i.e. when you have code that's 'hot in your mind' and can be re-worked.

Another key that the article doesn't seem to reference is encapsulation. It's one of the most golden concerns in software.

If 'ugly' is confined to a single function and doesn't leak outside - <USER2> it's almost pointless to re-write it.

On the other end of the spectrum, if an API is 'ugly' it leaks all around the code inside and out. Re-write is more expensive, but could possibly be more worth it.

<comment><USER21> Rewriting an ugly API could be problematic if not rewritten while fresh. Once it starts being refed everywhere good luck.. I bet there are no test cases either and the task becomes daunting and expensive

<comment><USER20> Yes, that's the thing. Exactly. APIs are by definition leaky. Look at Python v2 v3 debacle. So it has to be really well planned, even then possibly not worth it.

</comment></comment></comment><comment><USER22> So many good lessons for newer developers and good reminders for more experienced ones. It was due to the Bike Shedding Effect that I came to not appreciate code reviews. Every review seemed to break down into discussions of variable and method names. I tried several times to create "off topic" rules like no discussion of variable names, etc. It didn't work...ever.

Now that I've been away from mandated code reviews for quite a while I can understand why reviewers go to the trivial. Firstly, "code reviews" are really "system reviews". It's difficult reviewing a project whose requirements you don't know with a design that came about through iterative design and possibly in a language you don't use.

My current team is small and split into an integration group (mine) of two people and a UX group of two people. My group partner and I look over each other's projects and stay up on the requirements as the project progresses. But it's completely informal. Yet it seems to work better than having a group of 2, 3, X number of randomly chosen developers from my department.

<comment><USER23> That's why pair programming works better than code reviews. Unless you have crazy amounts of time there is almost no chance a code reviewer can really understand the design of the change. So you end up with people picking on very local stuff like variable names. With pair programming you have two people who understand the history of the code and why decisions have been made.

<comment><USER24> But seriously, naming things correctly makes understanding the global system so much easier.

The whole point of naming things is that you don't have to dive in this 60 LoC function, but rather can use its name to know what it does, and make a global mental model.

If you're not naming things correctly, you effectively make it almost impossible to review the design, and that's why people starts with asking about names.

Reviewing names is the exact opposite of picking local stuff. Names have no importance locally, but they have tremendous one globally.

So, please, use good names ^^

<comment><USER23> Totally agree about the importance of naming. But the big problems that are hard to fix later come usually from design flaws, not from naming and often are overlooked in reviews.

<comment><USER24> I agree with you. My point, if it wans't clrear, is that I think correct naming is a prerequisite to finding design flaws in review ! Hence we have the same ultimate goal :-)

<comment><USER22> I don't find that to be the case. I'm usually looking for bigger things like: 1\. making multiple trips to a relational database when a single statement joining tables can make it one trip; 2\. not handling exceptions that can cause data loss or data corruption.

(I'm not trying to be exhaustive. The examples above are common ones I've seen regularly and they make me cringe.)

I don't need to know the variable names used in these cases. The very act of not using a relational database properly or not handling exceptions is easy to spot.

</comment></comment></comment></comment></comment></comment><comment><USER25> I call this, Developer Inertia: It's hard to learn others' code, but it's easy to fix to bugs in others' code. It's easy to write your code, but it's hard to fix bugs in your code.

It's good to have someone else looking at your work in established projects. Pair programming provides some value to overcome this problem.

Overcome your weakness, you'll become a better developer.

<comment><USER26> You call what? Can you be more specific?

<comment><USER27> I think the GP's

> I call this, Developer Inertia:

should read

> I call this "Developer Inertia":

</comment></comment></comment><comment><USER28> Naming stuff is not trivial and not a bikeshedding.

<comment><USER29> No, sorry. Wasting too much time is BS.

Use a good name and be done with it. You're naming a variable, not the title of your Magnum Opus.

Edit: I think people are reading too much into the initial dismissiveness and not going past the 1st line.

More important than picking the perfect name:

\- Being consistent with the naming (you called it a 'bolt' keep calling it a 'bolt' for the same type of object and for its life through the code path. If bolt is not a great name you can change later.

\- Being easy to remember and type. There's no point with TurningWheelThatGoesSqueak and having a TurningWheelThatGoesSquak and a TurningWheelThatGoesSquewk this will only make the developers go crazy. Simplify.

And yes bikeshedding is bad. I just find it too ironic that parent's username reminds me of the place that took bikeshedding to the extremes.

<comment><USER30> _You 're naming a variable, not the title of your Magnum Opus._

You're naming a variable, and that name is probably the most important documentation about that specific point in the code. A lot of the time a useful name will be quite obvious, so you should use one. If you see code that has variable names like a, i, myVar, value, etc then it's _usually_ a sign the developer didn't think very hard about the code that they were writing. Using a name that gives some context to the data the variable should hold is _massively_ useful to the next developer to work on the code (which is usually you, so you'll be thankful you did).

<comment><USER29> 'a' and 'i' are perfect for indexes or range traversals. Yes, myVar is bad.

You can always read the context and see 'for value in list_of_values' or understand what's it that you're working with right now.

Yes, be more explicit on the tricky parts, but sometimes i = i+1 is just fine.

<comment><USER30> _' a' and 'i' are perfect for indexes_

Except they're not as good as 'index', which is obvious and provides some meaning, so why accept single character name?

I have an eslint rule that blocks single character var names on my projects. It makes my team develop good habits, and no one has ever complained about it. Our code is very readable.

<comment><USER29> > so why accept single character name?

Because readability suffers with repeated long variable names

There's a reason why math uses i,j,k and x,y,z and it's not to be petty.

<comment><USER30> There's also a reason why a lot of people find equations incredibly hard to parse.

<comment><USER31> This is a nice semi-random deeply nested spot to observe how the topic of naming is so cognitively attractive.

Even in the meta-sense it is being discussed here.

There is something about naming that we like thinking about, and fine tune our thoughts on, more than a simple need for legibility.

There is a sense of ownership in picking a name.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32>
      // TODO it works, but it's ugly, rewrite
      function init() {
          // some code
      }

What is ugly, what would rewrite accomplish? Excellent example of bad commenting. Comments are ideally unnecessary, so bad comments just litter code and stink it up even more. No code will live forever anyways, and it says something about someone when they falsely believe in perfection.

<comment><USER33> I write similar comments sometimes, although a little more descriptive. It's to acknowledge that this snippet has some issues and could be improved, but for whatever reason not now.

I also go back sometimes and do just that. without the comment I forget 95% of the time.

</comment></comment><comment><USER34> Worth the click even to just skim the hilarious images that illustrate the points.

</comment><comment><USER35> I think line anxiety might be another one. Unless it's just me. If I feel that a function or a file is just irregularly long compared to the others, I find myself asking if I need to break this thing up to be more abstract

<comment><USER36> Definitely not just you. To quiet such anxiety, I usually ask myself whether the length of the function is affecting the readability and speedy understanding of the logic. Longer functions are not necessarily bad, but if they pack so many logical units and so many scope variables, they could be improved.

</comment></comment><comment><USER37> > When you look at complicated systems and clever solutions - most likely it > took a lot of time and resources to implement it, but all you can see is the > smooth result. It is easy to fall into this fallacy because complex > solutions always require a lot of work, testing, and iterations.

I used to have this problem all the time with the managing director:

MD: Company X has a really nice and simple help system. Why can't we do the same?

Me: We can, but we need a product owner, a designer, a developer and a tester full time on this for at least a couple of months.

MD: I don't understand why we can't just copy what they did.

<comment><USER38> "MD: I don't understand why we can't just copy what they did."

What was your reply?

<comment><USER39> We can. They have a product owner, a designer, a developer and a tester full time.

</comment></comment></comment><comment><USER40> If the author reads this: Dark theme completely FUBARs the code snippets.

Sample: [https://i.imgur.com/QUO48fn.png](https://i.imgur.com/QUO48fn.png)

<comment><USER41> How did you change theme to Dark?

<comment><USER11> Happened automatically on my device, probably because I have macOS running in dark mode. It's a feature. Switch your OS to the color scheme and language you prefer and websites / apps should adjust accordingly. Should. We're not quite there yet.

</comment></comment></comment><comment><USER42> Not all code is critical and intended to maintained forever. Everyone is not working at Google, Amazon etc. most code I write is not run daily by 1000s of users.

<comment><USER18> Maybe there are just lots of FAANG engineers on HN, but it's amusing how many people overestimate the size and scope of the projects most software developers work on. There's so much discouragement and pessimism if a software wasn't written to handle millions of requests, or intended to live on for 15+ years.

On the contrary, there's software written all the time that has a realistic lifetime of a few years before it's either replaced with a 3rd party alternative or rewritten by some disgruntled programmer. Deadlines and business priorities often mean that foregoing what most of us would tout as "best practices" actually makes sense. Some software is only used by 10 people at a time, and can be maintained by one or two engineers. It probably makes more sense for the engineers to choose what's best for them and the company over what most people would say are the right things to do. There are people I know who don't write tests for their software(something I don't know that I would ever do), but each piece of software they write is small and has a lifespan of a few years at most, and the advantage to removing barriers to development is that they can make changes very quickly and get things done.

<comment><USER43> But, how would the developer know about the lifetime of the code. How would the developer know if code will never be extended or will remain stale for the rest of the life?

<comment><USER11> Exactly this. I'm working on a codebase right now that looks like it was written by someone who had barely finished school, figured out how to use a function in JS to produce the HTML for an input element inside of an XHR response callback, then just kept reusing that over the next eight years leading to multiple >10K LOC files. I'm not sure the original author ever intended the application to be around that long.

</comment></comment></comment></comment><comment><USER44> I've been putting off writing about similar subjects. This is a favorite genre for me.

I often consider path dependence in product development. The decisions we face for any given circumstance is limited by prior decisions and experiences, even though past circumstances may no longer be relevant.

</comment><comment><USER26> Also about trade-offs of clean code [https://overreacted.io/goodbye-clean- code/](https://overreacted.io/goodbye-clean-code/)

</comment><comment><USER45> Image selection for the article is on fleek!

</comment><comment><USER46> Best laugh I've had all day.

</comment><comment><USER47> by who can pay?

</comment><comment><USER48> The entire human race is a cognitive bias, you can't have christians and muslims be right at the same time. One population of religious people must be wrong and therefore a huge portion of the population must be cognitively biased to an extreme degree of believing in something completely wrong.

It is part of human nature to be hugely biased to a completely absurd degree and software engineers and scientists are not immune to this effect.

The worst that I've seen this in (to the best of my ability, as I'm cognitively biased too) is in design patterns.

Typical scenario:

Object instantiation requires 50 parameters to be fully realized. Some coworker suggested that we instantiate an object with empty members and create 50 methods on an object that each take one parameter to load the object.

Apparently having a function that takes 50 parameters create the object was a code smell because it didn't have a fancy name. That fancy name was "builder pattern."

If you can't see how utterly stupid builder pattern is for this case... well... cognitive bias.

<comment><USER49> > If you can't see how utterly stupid builder pattern is for this case... > well... cognitive bias.

You cannot win against the prevailing wisdom. Try having a public mutable field on a class, and watch people lose their ever-loving minds. But why do we have more than half of the classes' exposed with getters _and_ setters? Mmmmfh.

I think the problem is that it is really hard to reason about software in the large. So we reason about software in smaller and smaller granularity, e.g. classes. And then we want to load down every single class with armor as if it needs to be protected against the wild hordes of unwashed masses who will rampantly mutate it. But most classes naturally fit into a larger unit, a cohort of classes, and they are coupled with each other, and they mutually share state. You can't understand the whole thing by staring at a single class, anyway. But it _feels_ like we are doing the right thing because we are told every class needs armor. Nevermind that now every class is 3x bigger, and so the whole thing is 3x bigger, which makes it 9x harder to fit in your head! Uggh!

<comment><USER31> Well, obviously the simple solution is not to use getter/setter methods but simply overload the implicit get and set operators of the field when you do need to track or react to field value accesses and changes.

Not a language option? ... Oh, so simple ... and yet, so far away.

<comment><USER48> No dude. The solution is not to use the builder pattern period. Just have a function/constructor with 50 parameters.

Why? Because the instantiated object requires all 50 parameters to be fully realized. Having to call 50 separate setters means you can create an "invalid" object where only 23 setters are called. Why allow this to happen at all? It's like a null value, why allow that value to exist on a type?

If you need all 50 parameters to be fully realized, then the logical thing to do is to only allow the object to exist with all 50 parameters in place. A constructor with 50 parameters insures that this fact is reality. It's that simple.

Yet even you, with the answer right in front of your nose staring you in the face still thought that you 50 setters is okay with syntactical sugar! That's how powerful cognitive bias is with design patters. "Builder pattern" is a word that lends a sort of artificial aura into what is essentially stupidly dividing up a constructor into 50 setters for no good reason.</comment></comment></comment></comment>