Software has diseconomies of scale, not economies of scale
&gt; Suppose your developers write one bug a year which will slip through test and crash the users&#x27; machine. Suppose you know this, so in an effort to catch the bug you do more testing. In order to keep costs low on testing you need to test more software, so you do a bigger release with more changes - economies of scale thinking. That actually makes the testing harder but… Suppose you do one release a year. That release blue screens the machine. The user now sees every release you do crashes his machine. 100% of your releases screw up. If instead you release weekly, one release a year still crashes the machine but the user sees 51 releases a year which don’t. Less than 2% of your releases screw up.<p>This example makes no sense. The user in either case still gets 1 crash per year. They&#x27;re actually worse off in the many-releases case because in the annual update scenario, they can at least block off a few days to cope with the upgrade scenario (in the way that sysadmins schedule upgrades and downtime for the least costly times of years), but in the weekly release, they could be screwed over at any of 52 times a year at random, and knowing Murphy, it&#x27;ll be at the worst time. &#x27;% of releases which crash&#x27; is irrelevant to anything.