As someone who has believed in the ideals of Test Driven Development for several years, I often find it unfathomable that some folks are still stuck in what I call F5 Driven Development. Defining this term is quite as simple as stating “Write some code, press F5, see if it worked, close, repeat.” You can be running a F5DD cycle and not even realize it. Any time you’re developing and you do not have a short, fast way to test changes several times per minute, you’re essentially in the F5DD cycle. This applies to writing all types of applications: web, fat client, mobile, Silverlight, Windows services (oh dear, don’t get me started about F5DD and Windows Services). Silverlight is a special and sad case as well, as I cannot think of any other technology where F5DD is the only way to develop most of the application.. ok, well there IS Flash as too.
First, let’s talk about our attention span. It shouldn’t be news to anyone in the tech industry that the Internet with it’s immediate access to a universe full of information has contributed to the majority of us having very short attention spans. There have even been some studies that say knowledge workers often have the attention span of a sparrow. Ironically, Twitter cuts the short attention span to a whole new, lower, level. When following enough people, “drinking from the fire hose” is no longer an accurate analogy… it’s much more like having an ocean’s worth of water shot at you through a 12′ diameter pipe. It is my belief that these constant bursts of short information are a detriment to our ability to pay attention to any one thing for a substation length of time. Even writing this article, I’ve switched over to Twitter at least 20 times.
So what does this have to do with F5DD? One of the biggest problems with F5DD that many articles do not cover is the loss of attention which is supposed to be dedicated to the problem you’re trying to solve. Observe this typical process (bare with me, Ruby guys):
- write a bit of code
- wait for successful compile
- press F5
- wait for app to spin up (potentially having to recompile again)
- navigate to and test feature
- close app
- and then wait for your IDE to come back around so you can start the cycle again.
These wait times can be very damaging to your attention span. In the world of writing an ASP.NET application, even on a beefy computer, with a medium sized code base, you could very well be waiting for at least 30 to 60 seconds before the application starts up. Only at this point can you begin to manually test your feature. Have you ever been through such an experience? The delay between typing the last character in the code and starting to test gives your mind ample opportunity to start wandering off… “I wonder what’s happening on Twitter now?” “Better check my email again, though it’s only been 2 minutes” “Ooo I should go get some coffee!” “I’ll just play with my new Android while I wait” “*zombie drool* FACEBOOK *zombie grunt*”. All of these distraction points contribute to a further loss of concentration, and result, ultimately, in sub par code. When you finally get your attention focused back to the problem again, you may find that you’ve forgotten the last change you made, or an idea about where to head next with the solution.
How does TDD solve this problem? The easiest elevator pitch I can give you is “speed, and lots of it.” Generally speaking, applying the practice of TDD gives your brain less time to wander and become distracted. Of course this is no absolute, and I can site many times during the TDD process that I have still become distracted and succumbed to the urge to check my email/twitter/phone. The important distinction is that during TDD, the distractions come at a decreased rate. The less time we give our minds to wander, the more we should be able to stay focused, at least theoretically speaking.
Next time I’m going to tackle another important player in the battle against becoming distracted during the coding process, slow test frameworks and test runners (I’m lookin at you, Gallio!). Afterwards, I’m going to take on the tough issue of sleep deprivation and how poor code quality can be a direct result.