We shipped every year, or maybe every 6 months. What this meant in practice is that every team got their features to "shoddy" state, but one team would always take much longer to get there than the others, and because we were in a "feature freeze" near ship dates, the teams who were waiting for integration could use that time to clean up their features, applying craftsmanship to make things "shipshape"; products could ship with one or two wobbly new features, and most of them pretty solid.

Now, with internet updates, as soon as a team gets to "shoddy", the feature ships; no one polishes; and all new features tend towards wobbly. (for the business this is an advantage, as features are stabilised only in response to demonstrated customer demand, but I think the enforced opportunities for cleanup on the old schedule, however disadvantageous for the business, were advantageous for engineering, as well as those customers who hadn't explicitly signed up for the beta program)

Also, maybe there’s an ironic counterfactual in payment and financial reporting networks, like Visa and Peppol. Peppol is not for profit, and Visa infamously facilitates five-way transactions with a huge degree of backwards compatibility.

As an aside, I wonder what code quality means to the author of TFA, and what craftsmanship looks like. Would be fantastic to get clear examples of this from the history of the industry.