For Students and Mentors of Test Driven Development
As a consultant who is often sent in to mentor teams of developers on Agile practices, it is always interesting to see the reaction that a lot of developers have to the practice of Test Driven Development. The reaction that I almost always see (initially) is one of uncomfortability and apprehension. Looking back almost 3 years to when I started practicing test driven development, I have complete empathy for people in that situation. In my personal opinion, when you undertake the task of getting to grips with TDD you have to ask some really hard questions about "what you think you know".I have found that having a solid OO background is paramount in utilizing TDD effectively on software projects (assuming the OO paradigm is in effect). This is often a time when many developers have to stop and really question their true solid knowledge of fundamental OO concepts. Often times, developers are quite surprised at how much they still have to learn about good object composition and responsibility assignment.
I have seen two different kinds of reactions to this realization. People can choose to humble themselves and realize "hey, I’m willing to admit that although I thought I had OO concepts down pat, I obviously don’t and want to make a change." These people are "highly coachable". They are willing to relinquish any assumptions they have about their knowledge of object oriented concepts and essentially relearn a lot of the basics in order to make themselves more effective developers. Of course, this is a process that can happen quite naturally when they are being coached by someone who is trying to teach them TDD. The other set of people are the ones who are not willing to admit that they may not know as much as they think. They will initially fight the coaching every step of the way because "you can’t teach me anything new". I have definitely run into my share of these people over the years. Even then, I do not like to put these people into an "uncoachable" category. I believe that once you have gained people’s trust and they realize that you are actually there to add value to their project/skillset, even people who seem "uncoachable" often open up to new ideas. It just takes time.
I like to think of learning TDD as equivalent to learning to snowboard. Lots of snowboarders who have been involved in the sport for a while often encourage new learners to take at least one lesson from a seasoned snowboarder. Half of the new riders will attempt to learn to snowboard on their own. Will they get it? Yes. Will it take longer than if they had picked up tips and tricks from an experienced rider? Yes. Is there a possibility they will develop bad technique? More than likely. Learning TDD on your own is actually very similar. There is no better way to learn TDD than to pair with someone who has been involved in the process for a while. They will be able to pass down techniques and tricks that you can immediately utilize to improve the quality of the tests that you write. They will be able to teach you about the value of using mock object and dependency injection to write more loosely coupled code. They will be able to allow you to identify how to test objects in isolation and how not to test too much at a time.
No More Idols
This brings me to talking about humility for the coach. It does not matter how great I think TDD or other agile concepts are. Often times, teams I go into work with are going to be experiencing these concepts for the first time. I cannot go into these environments with a "Holier than thou" attitude and expect them to be receptive to what I have to show them. Mentors and tech leads, I have to stress this point loud and clear.
Just because we ’may’ have more experience and knowledge than the people we are coaching, we are in no way better than that person in any way shape or form.
Whole sets of people are being alienated because they are being made to feel inferior as a developer; and worse, as a person. One of the biggest problems a lot of people have when trying to work with people who are coaching them on TDD principles is the fact that the coach really does not have the patience to teach in the first place. Why is patience paramount? 80% of the time spent teaching TDD will actually be time spent unravelling years of bad habits that need to be broken to become effective at TDD. Often times, these habits are things that the coach also had to break when starting down the TDD path. Which is why it is essential for mentors and coaches to "Remember where you were when you started down this path." TDD is a paradigm shift for developers, it takes time (just like good OO skills take time and practice to hone) to get:
- A – Comfortable with the shift
- B – Proficient with the application of TDD
In conclusion I would like to finish by saying that people can have great success adopting TDD when the right person/people are there to aid them in the process. It takes humility on both parties involved to ensure that the transition is as smooth as it can be. There is a lot of buzz in the industry around TDD and agile concepts right now, and I personally think that is a good thing. There are a handful of good TDD practitioners out there in the blogsphere / presentation circuit who are extremely pumped about spreading the "good news" about TDD. With all that said, every developer individually needs to determine whether TDD is something that works for them. Like anything else in life/software, you need to give it an honest educated shot before discounting it completely. My last piece of advice regarding TDD is this. Anything new in life/software always makes us feel a little uncomfortable. It is our responsibility to either ignore something new, or give it an "educated" shot, before discounting it completely. Don’t discount TDD until you have had the opportunity to see/use it effectively. It has personally changed the way I develop software, and I could honestly say that I couldn’t go back to not using it.
If you ever need someone to come in and coach your team / give a presentation on TDD don’t hesitate to contact me. It would be an honour.