Experiment: The costs of slow build times
Please, step me through this. In a start-up:<p><pre><code>  a) Developer builds locally
  b) Developer tests locally
  c) Developer pushes to a repository
  d) CI starts
  e) CI ends
  f) Wait for human code review and approval
  g) Merge and deploy
  h) Observe that nothing broke &#x2F; no need to revert.
</code></pre>
Is it even possible for (e) - (d) to be short enough, let alone (f) - (d), to keep the developer&#x27;s attention instead of context switching? Most devs I know just context switch immediately after (c). If you care about developer productivity, you&#x27;re much more likely to get results from focusing on (a) and (b), by hooking development laptops into caching and restricting system&#x2F;test scope, than you are by reducing CI times, unless your CI takes some ungodly amount of time to run (several hours).<p>For point of comparison: article examines how using monster machines can reduce the build time of Fedora to 27 minutes (not really a comparable example to most companies, but OK). My devs complain about an (admittedly unoptimized) CI time of 20 minutes (on a much simpler project than Fedora) that introduces context switching. Is the article really trying to get me to believe that Fedora developers wouldn&#x27;t context switch on a 27 minute build, twiddling their thumbs for 27 minutes, but that a 35 or 55 minute build would? Something about getting under the 30 minute bar gets developers to keep their focus? I call bullshit.