5 ms·
To be fair, quarterly and annual release cycles were common when software was a physical product. Games had to sell retail, and enterprise software still needed
by landryraccoon 11y ago
To be fair, quarterly and annual release cycles were common when software was a physical product. Games had to sell retail, and enterprise software still needed to deliver disks. Until the early 2000s there was no point in continuous integration because your release process still had to be waterfall - you were gated by extremely slow physical processes like retail outlet logistics.
Once continuous deployment to the end user was possible (via the internet), the industry started following suit. And nowadays there is still something similar for iPhone developers - you're gated by the Apple app store, which doesn't have to be slow, but somehow still is. (This has important implications like having to backload a huge amount of testing before app submission because you can't be certain of how quickly you'll be able to release a frontend patch).
- wpietri 11y agoSure, the shift in delivery mechanisms provided a lot of incentive to move to faster deployment. But I should note that a great deal of software in ye olden dayes was in-house software, and that still ran on 3-18 month cycles. And that wasn't because of technological limitations; my dad was delivering new versions of software every few days even in the 70s. It's just that the conceptual model and the dogma pushed in the direction of long, heavily-planned release cycles. The Internet's main contribution here was to make short cycles not only possible for commercial releases, but competitively advantageous in an obvious way.