Monolithic Releases

Monoliths are hard! Releases require full-org synchronization with stabilization periods and possibly-expensive integration testing environments.

There is a stabilization period every release cycle. The minimum release cycle time is driven by the duration of the stabilization period: we only want to release often enough that the transaction cost is justified.

Verifying a feature requires teams to run integrated code in some lab environment --- and those often become expensive to run. Verifying system properties, such as security or non-regression, requires large amounts of testing (human or automated) in the integration labs.

Even building code is hard. Each compile takes a long time, as developers have to check out and build large amounts of the system to change any one part. This creates cover that allows slow tests to fester, so the test cycle gets even longer than the compile. Verifying non-regression over the actual scope of potential impact for a change becomes prohibitively expensive, so the team develops shortcuts that allow them to verify non-regression over the "most likely" parts. This allows some failures into the commit stream, which the build then has to detect and handle. Because CI takes so long, build systems become complicated, able to batch changes and then unbatch them on error, handling tentative pre-commit, with a confirmation after CI, and so on. Building and maintaining these smart pipelines becomes an overhead tax on the organization.

People require high discipline in order to succeed. They need to trust the build signals --- even though those signals tend to have many false failures. They waste a lot of time re-running verifications and debugging issues that turn out to be phantoms. The alternative is to waste even more time unwrangling a problem while the rest of the company is unable to verify their work (build is broken). Because real-world discipline is never perfect, build breaks are a regular tax on dev productivity.