Distraction: No Longer a Four Letter Word, Thanks to TDD
While researching for a talk that I will be giving at the Ability in Tech Summit in Berkeley, I have come across various strategies and tools that developers use to deal with ADD and other learning disabilities. I myself have tried many of them during my 8 years in the tech industry before I joined Pivotal Labs. For example, I have tried setting timers for myself to help stay focused and on-task. I would set a timer for 15 minutes, and when the timer ended, if I was off-task I would have to self-correct and restart the timer. The “timers & reminders” strategy, however, still has its downsides while programming. The timer itself is not part of the programming process and could potentially be the very distraction we are trying to prevent. There have been times when I was working smoothly and the timer would interrupt my flow. Another strategy is to schedule “distraction-free” time during which other people are discouraged from approaching the differently-abled programmer and also institute specific times when the ADD employee can be a “people person.” I think that setting arbitrary guidelines for one’s workday behavior without regard to the actual tasks at hand is counter productive. These and many of the other practices commonly recommended to differently-abled programmers are specifically designed to suppress the powerful strengths that programmers with ADD possess in favor of conforming to workplace and industry norms.
In my personal experience and through my research I have discovered that many of the unique traits that make up the adult with ADD, such as inventiveness, adaptability, and creativity, are in fact huge assets to the software development community and should not be stifled (check out Lara Honos-Webb’s The Gift of Adult ADD for more on this topic). Instead of strategies like the ones mentioned above, I allow test-driven development (TDD), which is already one of our core practices at Pivotal Labs, to scaffold my code creation process in such a way that distractions won’t even cause a problem. It is a natural and powerful method to aid the differently-abled programmer
When we use TDD at Pivotal Labs, we are fundamentally starting our code writing process from the user’s perspective. Often we start by writing or modifying a feature test to describe the new behavior that we expect our application to fulfill. Of course, the test will fail because the code has yet to be written, but now we have scaffolded the task at hand. TDD requires discipline to engage in this step-by-step approach because it always follows this specific path: express the desired behavior in the form of a test, watch the test fail, then implement new code until the test passes. The algorithm is naturally recursive: you might start by writing that failing feature test and find yourself writing a failing unit test for an inner module while the feature test is still failing.
As developers continue to write code using test-driven development, they find their work continuously scaffolded by the tests they have written. It is this continuous scaffolding that allows the programmer with ADD to no longer be afraid of distractions. I used to fear distractions as the greatest enemy to my productivity. With TDD, I don’t have to expend any extra energy to fight against the myriad distractions that occur in any software development environment. I simply let the distractions in, whether they be a question from a team member or a client who needs support. But I have confidence today that when I come back to the code, I can just run my tests, see what is failing and pick up from there, because a failing test will always tell me what to do next.
