The best software is that which never ends, and in order to write software that never ends, you must keep the programmers happy to continue adding to an ever growing language. Test driven development (TDD) is used to create code that is tested and self documented, and to create a programming environment that can last forever. In addition, two interesting side effects emerge from practicing TDD: the design of a project evolves out of the tests, and all programmers on a project have a common language to communicate their ideas. Some perceive the design element heavily and rename test driven development to test driven design. The common language that emerges allows all developers on a project to easily vet out a decision by asking their peers: “Do you understand this test?” and then, “Can you make it pass?”
When using TDD, a certain mindset should develop in the individuals employing the practice. In a pair environment, the minds of the two programmers merge into one. A test is written, the other developer adds code to make the test pass, and the code is refactored to remove duplication and increase clarity. Each one of these write test/make test pass/refactor code cycles becomes a single unit of time to the developers. While this TDD cycle may take 25 minutes for inexperienced developers, or an experienced developer teaching an inexperienced developer, that cycle becomes a unit of measure. As developers, we strive to minimize the time taken for each of these units, and once we begin to approach TDD cycle times around 5 minutes, we’ve become professionals at the TDD mindset.
The TDD mindset is difficult to attain, and I liken it to a moment of clear awareness. Every line of code written happens effortlessly, and the real thinking is involved in which test to create next. A pair of TDD developers must share this awareness, be free from distraction, and they must have a shared vision of what the code should produce. There are many common ways to increase our TDD mindset:
- Removing all distractions – anything can be subject for removal here: phones, games, conversation with others outside the pair
- Asking questions – When pairing, sometimes you start with a clear understanding of what your next test should be, but most often the pair begins by discussing how to approach a new problem. In the latter case, asking questions back and forth can help to get the two pairs to a shared understanding. The pairs should leave their egos at the door; however, and be willing to admit that they do not know the answer to any question their pair may pose. It takes much give and take to make this work without frustrating each other, but your two minds will be much closer in synch when beginning to tackle the problem.
- Drawings and diagrams – everyone understands the language of pictures, and while there is always room for interpretation, it can help to have a diagram visible during a pair session of what the end goal should be. It does not have to be UML, but it should clearly show classes and how they will communicate with another
- Common design patterns – each member of a pair should be knowledgeable of patterns and how they relate to code. Factory, singleton, builder, decorator, and adapter are all needed daily. More advanced patterns such as MVC (Model View Controller) and MVP (Model View Presenter) can be used if the team has agreed on how they fit into the project.
- Listening and communication skills – This should go without saying, but every developer should actively engage with their pair and truly listen to the answers provoked by questioning one another. You may believe your way to be correct, but if your pair does not understand the solution the same way you do, there will be more confusion down the road.
- The Pomodoro technique – To summarize, this means to create a time frame in which you will be entirely focused on the task at hand, and then to rest for a small time frame afterwards. A task time of 20 minutes, with a 5 minute break in between works well. Most smartphones have timers, so this is very easy to implement.
If the goal is to create a software project that will continue to grow for years to come, then the team will want to make sure that the project is a safe playground that they can all enjoy working in. The testing and pairing element help to keep the project secure, and the TDD mindset will keep the team productive while staying completely tested. As the leadership keeps the team shielded from outward pressure, an environment is created that promotes personal and professional growth. As time goes on, everyone on a team will grow as individuals, and they will be ready to tackle the ever-growing problems that the world throws at them.