A slow development test cycle will kill your software.

New developers won't want to learn your project, because they would rather shoot themselves.

This means that build time, and the time to run tests, must be short.

5 seconds to rebuild is the maximum upper limit.

Of course, at some point software gets large enough that things won't fit anymore in 5 seconds. But then you \i[must] have either some kind of build caching, or options to do partial builds/tests that will bring things down to that 5 second mark.

You also have to spend some time profiling execution and build from scratch times.

A slow build from scratch will mean that your <continuous integration> costs a lot, money that could be invested in a new developer!

It also means that people won't bother to reproduce bugs on given commits, or <bisection (software engineering)>[bisect stuff].

One anecdote comes to mind. <Ciro Santilli> was trying to debug something, and more experience colleague came over.

To reproduce a problem, ciro was running one command, wait 5 seconds, run a second command, wait 5 seconds, run a third command:
``
cmd1
# wait 5 seconds
cmd2
# wait 5 seconds
cmd3
``

The first thing the colleague said: join those three commands into one:
``
cmd1;cmd2;cmd3
``
And so, <the correlation between software engineers and Buddhism>[Ciro was enlightened].

\Image[https://web.archive.org/web/20220930224719im_/https://imgs.xkcd.com/comics/compiling.png]
{title=<xkcd> 303: Compiling}
{description=They should be benchmarking and fixing their shitty build system instead.}
{source=https://xkcd.com/303/}


The development cycle time is your god

ID: the-development-cycle-time-is-your-god