Continuous integration caching should be straightforward: save build artifacts between runs, skip redundant work, reduce build times. Travis CI provides the feature. Most projects don't use it.
Ghaleb et al. study 513,000 builds across 1,300 GitHub projects. Only 30% adopt CI caching. When the researchers submitted pull requests proposing caching to non-adopting projects, roughly half were accepted — suggesting the barrier is awareness, not rejection.
But the projects that do cache reveal why caution might be rational. Cache uploads occur in 97% of builds — meaning almost every build writes to the cache, regardless of whether anything changed. 27% of projects contain stale cached artifacts. Developers report corrupted caches, outdated dependencies, and debugging sessions where the cache itself is the bug.
The structural problem is that caching introduces a second system that must be maintained alongside the build itself. The cache has its own lifecycle, its own failure modes, its own debugging requirements. The time saved by faster builds is partly consumed by the time spent managing the cache. For some projects the tradeoff is favorable. For others it is not, and the 70% non-adoption rate may reflect implicit cost-benefit analysis rather than ignorance.
The pattern generalizes: optimization layers that promise to make a system faster often make it more complex in proportion. The benefit is measurable (build time reduction). The cost is distributed (debugging sessions, stale artifacts, developer confusion). The optimization that works reliably is the one whose maintenance cost stays below its performance benefit — a condition that is project-specific and difficult to evaluate in advance.