The other day I heard a sad story about a build that was broken for weeks due to a bug introduced in an open-source library. It took the maintainer a long time
to fix it (they're not getting paid for this, no criticism). In the enterprise they had so many layers of repository caching the team couldn't escape the buggy version. Even sadder, that library existed for fancy terminal output of a library that produced documentation (typedoc). A nonessential feature of a nonessential
build step blocked deployment. This is not OK.

Such fragility is an emergent property of the standard software delivery procedures today. All build-time dependencies are lumped in, and any failure in the build pipeline fails the whole thing. Atomist lets me solve both of these.

When I have a software delivery machine (SDM), I can remove typedoc as a dependency of my project. Instead, I install it globally in my SDM's container. This gives me consistency across projects and removes a snarly dependency from all of them.

Second, the SDM creates a graph of goals to aim for on each push, not a pipeline. I can include typedoc as a goal, but not make deployment depend on it. At the very least, I'd program my SDM give me an override button for the type doc failure and
continue with deployment.

push triggers compile, which triggers test and typedoc; test success triggers deploy; typedoc can fail without further consequence.

Atomist gives me choices about my software delivery.  It gives me the tools to build what I need, and lets me define that in code, with maximum flexibility. In modern software systems, we all deserve this.