Sponsored Link •
Writing tests before writing code is a key tenet of extreme programming: Write your tests before you write your code. I find myself violating this XP rule very often. A bit of psychology suggests that test-first development may actually stifle creative flow.
A key XP tenet is to write unit tests first, and then the simplest code that passes those tests. As the Extreme Rules state,
"When you create your tests first, before the code, you will find it much easier and faster to create your code... Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests."
I find myself violating this tenet of XP very often. I do test all my code, but often only after I've already written that code. Why does this one XP rule seem so out of place to me?
I may have come close to the answer in the work of the famed psychologist Mihaly Csikszentmihalyi, professor and former chair of the psychology department at the University of Chicago. Csikszentmihalyi (pronounced ME-high CHICK-sent-me-high-ee) is best known for his decades-long research into the key causes of happiness, and for his seminal book on Creativity. For that work, he interviewed several hundred scientists, engineers, writers, artists, philosophers who shared the distinction of having achieved remarkable feats of originality in their work, advancing their respective fields. Csikszentmihalyi wanted to find out what these people had in common that contributed to their exceptional creativity.
One shared thread: Their experience of "creative flow" during their peak mental work. Being in a state of flow means
"being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you're using your skills to the utmost."
Csikszentmihalyi identified four ingredients that must be present to experience flow.
Writing code in a certain way can help us get in a state of flow. For flow to occur, we must work on a chunk of problem at the right complexity level - a problem that's neither trivial, nor overly complex. We must have a clear objective for what we're working on -- for instance a specific, well-defined use case. To receive immediate feedback, we must unit test the code as we write it. Finally, it should be possible for these small pieces of functionality to work on their own, without having to go through major integration steps.
Most XP practices facilitate these conditions - with the exception of test-first coding. In my experience, writing tests first often interrupts flow. I can think of a couple of reasons:
In creating the tests, I often find the need to refactor the initial code into smaller methods that are easier to test. But those small methods serve mainly the purpose of easier testing, and perhaps better comprehension of the code by other developers - they are a secondary artifact, created after the initial deed of writing the code to perform that focused, well-defined task. Refactoring and testing are less creative than writing the initial code and, instead, are more "mechanical" activities.
I like to think of refactoring and testing as editing. When writing an article, most writers first create an outline, then write the content, typically in a few sittings, and without regard to mistakes, typos, sentence structure, etc. Only then does an author spend most of his time on editing, fine-tuning, and polishing the article. "Writer's block" often occurs when a writer intermingles editing with the initial "brainstorming" and creation of content. Most writers would agree that editing is a very different kind of activity from coming up with the initial content.
Looking back at some of the more complex systems I worked on, I always developed the trickiest part of the code that way - in one sitting, just getting it to work from beginning to end. I can often get a lot of work done that way, and produce a lot of functionality in a short period of time. In other words, that is a very creative time period. Then I spend some time on testing and refactoring.
I am curious if my experience is shared by others: Do you really write your tests first?
Extreme Progamming "Rules"
Creativity: Flow and the Psychology of Discovery and Invention.. Perennial, 1997.
Mihaly Csikszentmihalyi. Flow: The Psychology of Optimal Experience. Perennial, 1991.
|Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market.
Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.