Software has economies of scale in distribution. In fact the economies of scale of software are the key point of how software businesses are causing disruption. A single software program can be replicated infinitely at zero cost and allow anybody who has 1 liter of milk to have 1000 liters of milk at no additional cost. So in the author's example, software would be the same price for both 1 and 2 liters.
Complexity is something completely different and is well known in all products. I can design a calculator that adds numbers very easily. A calculator that does fractions is much harder to design and costs more. A car with a more complicated engine is much harder to build than a simple engine. This has nothing to do with the actual economies of scale of the calculator or car or you could say that cars have dis-economies of scale too - and obviously they don't. They're the poster child for economies of scale.
Building a truck that is 10km long is worse than building 100 trucks that are each 100m long, but this has nothing to do with 'diseconomies of scale' inherent in trucks.
You're responding to an argument the author doesn't make with a fact he is aware of. That's why he wrote: "once the software is developed then economies of scale are rampant". You can't distribute something before it is developed.
Most of this HN thread seems merely a reaction to the title—specifically the failure to say "development" in the title—which is a shame, because the point it makes about staying small is a critical one. If we don't even understand this here, the odds of any large group ever understanding it seem negligible. Another diseconomy of scale I guess.
Not at all. Let me quote the article then if you can't see it.
> Finally, I increasingly wonder where else diseconomies of scale rule? They can’t be unique to software development. In my more fanciful moments I wonder if diseconomies of scale are the norm in all knowledge work.
They apply to every known form of manufacturing, such as vehicles or genetic engineering of vegetables (the more parts of a vegetable you try to engineer, the more difficult it gets). The author seems to have missed this, which is what I was pointing out.
And on the idea that even developing software does not have economies of scale, I present the following: Linux. Linux is what we build everything on top of. Without Linux, we'd have to start from scratch. Linux is just code. Databases are the same way. We build our applications on top of thousands of lines of code and we utilize the economies of scale of everyone building off the same code to make our code easier to create.
So I'd say that not only does software have economies of scale in distribution, it must have economies of scale in production or we would not have operating systems or databases. The issue he is dealing with is a simpler one - complexity is hard to manage.
If you manage your complexity well and create a Linux or an Apache web server, then you have economies of scale. If you create a ball of mud, you have diseconomies of scale. If you build your 1km long truck out of well designed modular blocks, you have economies of scale in transporting massive amounts of goods along flat roads. If you try to custom build the whole 1km of truck, it will be a disaster. Nothing unique to software here, and diseconomies of scale are a failure of software design, not an inherent property.
For what it's worth, the actual term for this is the 'marginal product of labor'. It is a type of economy of scale, so I wouldn't say it's confusing, but it is a little weird to describe this way.
Perfect, bug-free software has economies of scale.
There is no such thing as perfect, bug-free software.
Once you start getting into any sort of maintenance, bug-fixing, feature creep- you lose all of the economies of scale of perfect software and replace that with the expenses the author discusses in the article.
You've possibly missed my point. The author made the statement that software differs from other items. It does not. Try making a 1km long truck and see if it's perfectly bug free. That doesn't mean trucks don't enjoy economies of scale.
Let me try another way to explain this: if software had diseconomies of scale, then selling each successive copy of your software that you made would make all the software more expensive. Eg, if I made a computer game and sold it to 1 person, I could do it for $10. If I sold it to 10 people, I would no longer be able to afford selling it for $10 and would need to sell it for $20 (x10 = $200 total). Makes no sense right? That's because software enjoys economies of scale. If I sell 1 copy of my game and want to make a profit, I need to charge $500000 to 1 person. If I sell it to 500000 people, I can get away with charging each person $0.99. The more software I sell, the better my economies of scale become.
Complexity is something completely different and is well known in all products. I can design a calculator that adds numbers very easily. A calculator that does fractions is much harder to design and costs more. A car with a more complicated engine is much harder to build than a simple engine. This has nothing to do with the actual economies of scale of the calculator or car or you could say that cars have dis-economies of scale too - and obviously they don't. They're the poster child for economies of scale.
Building a truck that is 10km long is worse than building 100 trucks that are each 100m long, but this has nothing to do with 'diseconomies of scale' inherent in trucks.