Trunk-Based Development

* realistic test input: either you carefully scrub actual production traffic and replay it (these require a ton of setup that doesn't age well), or you guess what you think users are doing and create dummy requests (and miss anything wacky you didn't know users do)

* load & perf: it's rare for a team to spin up a prod-sized cluster just for a test, and before AWS it was almost unheard of to go out and buy twice the hardware you need, even when you were lucky enough not to be deploying on your customer's boxes. A change that tanks your cache hit rate can ruin your whole day yet look fine at trivial sizes.

* visual design: Microsoft famously got bitten by moving away from manual testing that would catch dialogs made unusable by layout changes

We usually had best-effort integration tests, but they never caught everything, and we always had to make tactical decisions about when to release what based on risk.

The only reasons Excel and Visual Studio don't update constantly are 1) the update mechanism is too heavy with gigabytes packaged into an MSI, 2) it's easier to sell licenses with big updates, and 3) inertia.

With people migrating to Office 365, I wouldn't be surprised if the ship cadence of Excel (etc.) become more service-like, with frequent feature releases and only big redesigns or massive features getting released as "major version" releases.

(Disclosure: I work for Microsoft. These are my opinions and not based on any inside knowledge of Excel or Visual Studio dev/release processes.)

The issues around UI, documentation, etc are solvable. You can build and release features regularly without changing the UI significantly. The UI as a whole should be consistent but small tweaks are fine and big changes can be built behind a feature flag and left dormant until the next "big" release if necessary.

Documentation doesn't need to be locked to a specific version, or to the extent it does, you could automate that. From version to version, the changes that impact existing documentation are minimal. So your doc system needs to know how to render V1 and V2 and understand the delta between the two. Not free but not overwhelming either.

With all that said, I understand that sometimes "major version" releases and the associated "big bang" testing and signoff and release can make sense. But it's rare that continual release cannot work.

> I don't think it will ever be a good practice for large complex apps to change a tiny bit every day (Facebook might be challenging my theory, but their app is relatively simple they don't produce training docs, and most importantly they don't have to have the latest app compatible with all Facebook data from the beginning of time - instead they keep their data on their servers and modify it to the latest programs when necessary)

Chrome is getting close to this. They release major versions on something like a monthly cadence and smaller updates more often.

Obviously, the closer you get to a service model like Facebook, the easier and more appropriate it will be to ship updates very frequently. Over time, the number of devs involved in projects like this seems to be trending distinctly upwards, though. I wonder in 10 years what percentage of software will be shipped in a way that looks like "shrink-wrapped" software.

> I agree you could have more feature gating, but large backwards compatible file formats are a complex business already with 10 releases over a decade - I can only imagine what it would be like supporting reference-rich documents with many more releases and the additional complexity of the sender and receiver having to agree on a feature set (unless you make the feature set/flight implicit from the data - but that's a new kind of headache). We already have tons of code in new versions dealing with loading malformed data in old formats because of bugs closed years ago! Every document we wrote we must also be able to read.

I would think that binary formats would be pretty stable even if you released very frequently. I don't mean that it would naturally happen. I mean that it should probably be mandated. You shouldn't need to modify the binary format constantly in order for other work to happen. It would be a maintenance nightmare if every little release modified the file format. But this is kind of like shipping a binary client. You wouldn't ship the client as often specifically because of the maintenance cost (namely compatibility testing). Obviously if you couldn't do any work without changing the file format, then this would become problematic. But then I would wonder why your file format is so brittle and so tightly coupled with the rest of the app, and if I wanted to release rapidly, I'd invest first in fixing that.