ArticlesHere is a thought that was triggered while considering the impact of unit tests in my last post.
Context switches for the human brain are expensive – not only does it take time to remember what you were thinking before, but they offer an opportunity for distraction and to not return to the primary task.
Delays waiting for the computer offer a forced context switch.
This comes in many flavours, and can probably explain more behaviour than I had previously expected. For example, abandoned print-outs can be seen as a classic case of a forced wait, triggering a context switch and a distraction.
Large compilation time produces a common delay in the the workflow of a software developer. Perhaps scripting languages, such as Python, are (perceived as?) more productive than compiled languages not because loose typing unshackles the developer’s creativity, but because there are no large compilation delays in the workflow. Sure, they may run slower, but that slowness is typically spread out, never being boring enough to trigger a context switch.
I have often noticed that, in PHP development, the download of edited code to the test server takes up the same role as compilation in my workflow; just slow enough to facilitate distraction, but without the benefits of the forced poor man’s unit-test. I don’t perceive PHP development as particularly productive, but that may also due to my dislike of the poor language design. (To be fair, this is an issue with web-development, and the choice of PHP is theoretically orthogonal. In practice, I wouldn’t touch PHP for any other purpose, where I wasn’t forced to use it.)
Unit tests serve the same barrier. Sure they don’t need to be run as commonly as a compiler or ftp/rsync/unison, but they offer that speed bump in the workflow. No – speed bump is the wrong analogy. Traffic lights. Not only do they slow you down, but they offer you the opportunity to take a wrong turn while you are waiting.
Comment by Sunny Kalsi on April 14, 2010
I wrote about this from a slightly different angle. I think computers today are fast enough to compile code in the background. C++ code is still slightly slow, but not enough to break the flow. It’s when a lot of small changes add up, especially in the convenience factor, that things start pulling you out of flow.
Comment by Alastair on April 14, 2010
Yep; the longer the time between you hitting save in your editor and seeing the unit tests pass, the more opportunity there is to be distracted by shiny things on the internet.
One of the nice things about rails is that it doesn’t require a separate step for the changes to take effect. Surprised that PHP can’t be set up this way…?
Thanks linking to my toot (there’s a phrase that won’t be common in about 5 years time, I’ll bet). I wasn’t trying to say that compiling was an acceptable substitute for unit testing, as the phrase “poor man’s” sometimes implies.
Thanks also for not linking to the obvious xkcd comic (“compiling!”).
Comment by Mr Rohan on April 14, 2010
Have you got a null hypothesis? Perhaps the forced context switch helps you think [effectively a relax before another surge]?
My best development comes after a break ..
Comment by Julian on April 14, 2010
Mr Rohan,
My best development probably comes after a break too. But if that doubles my productivity, then coming back after a one hour break, and getting distracted again in 10 minutes at the next unit test run, is not exactly productive.
But I haven’t answered your challenge.
I guess the experiment would be:
Compare the productivity, on a unit-test friendly task, between two groups of developers.
Group A developers use Python and super-fast unit tests.
Group B developers use the same environment, but the unit-test framework is deliberately hobbled to take 30 seconds longer than required.
Group B are given additional time to complete the task – effectively 30 seconds extra for each time they run the unit tests. They should not be informed of this to prevent gaming.
My hypothesis: Group B will perform significantly more slowly, and will be observed to be distracted from the task for a greater period, exceeding the mere unit-test run-time.
The null hypothesis: Group B will either perform at the same productivity (perhaps because they can switch back to the task quickly while the unit-test completes) or at an improved productivity (because they can use the waiting time to work on their next task, or because their distraction helps to recover for the next bout of development.)
Comment by Aristotle Pagaltzis on April 16, 2010
Offered for consideration: Helpfully addictive: TDD on crack and (the follow-up) Some thoughts on tote.
Comment by Julian on April 16, 2010
Aristotle,
Offered for counter-consideration: A project that should be integrated with Tote: Nose Achievements.
Comment by Aristotle Pagaltzis on April 16, 2010
Oh man – you really want programmers to die at their keyboards, don’t you?
Comment by Julian on April 18, 2010
Wait, Aristotle, I am confused.
There’s another choice for us?
Comment by Aristotle Pagaltzis on April 24, 2010
Touché. 🙂