The “rule of eights” is a handy way to think about feedback cycle time and the effect it has on human attention spans. This is something I heard–and am probably misremembering to some extent–at an agile conference back in the day. I can’t take credit for this but I also can’t remember who I heard it from. If you know who came up with this, please contact me so I can properly attribute this.

(Edit: Dion Stewart points out that this resembles the Powers of Ten article from Jakob Nielsen. I’ve read some of Nielsen’s work, so it’s entirely possible that I have misremembered and conflated that with some other thoughts on feedback.)

The basic idea is that the speed of feedback has a huge effect on a person’s ability to stay in a flow state. The longer the feedback takes, the more likely the person is to context-switch onto some other activity.

80 milliseconds

Faster than human reflexes. Feels effectively instantaneous. Unlikely to break flow.

800 milliseconds

A noticeable hitch or pause. Enough to be annoying while typing, but not overly irritating when running a command. Reasonable for an “execute on save” command like linting or formatting. Unlikely to break flow.

8 seconds

A discernable pause. Cannot be a continuous part of workflow, but might be a kind of punctuation between tasks. Will cause thoughts to wander. May cause alt-tabbing over to check email.

80 seconds

Annoying. Enough to get bored and provoke tab-switching, with high likelihood of lost flow.

8 minutes

This is a coffee break. Certain to break flow. A diligent dev may alt-tab to HN with the intent to come back when the job is done (but will probably get diverted into other work until long after the 8 minutes is over.) Will cause the developer to find ways to avoid incurring this. If this is your test execution time, tests will degrade as they are avoided during most dev work.

80 minutes

Flow is a long-lost dream. This is a lunch break. Devs will organize their day around not having to run this job. They get basically two runs per day at this pace: probably once in the morning and once in the afternoon and the afternoon job may be kicked off before heading out the door.

8 hours

Flow? What flow? This is something the dev starts before leaving for the day. Everything is scheduled around this execution time. The job is very likely to break overnight, and devs will invent ways to “recover” a broken build via monkey-patching, hotfixing, etc. This is waste on top of waste, but feels more “right” than incurring another day of delay. The underlying job will get more and more flaky as people come to rely on spackle and grout instead of fixing the foundation.

8 days

Effectively infinite. Jobs very likely to fail. Flow is irrelevant. This is the domain of researchers, prisoners, and postdocs.