How Do You Convince Your Boss to TDD?

a reader asks:

my boss knows about tdd but won’t allow us to use it because he thinks that it is just a passing hype that everyone talks about but no serious, big projects actually use it on daily basis. how could i convince him that it is not so?

excellent question which takes me a bit by surprise, as i can’t imagine my boss dictating how i write code. i don’t have an answer but here is what i think i would do if i was in this situation. however i wold also like to encourage other readers to share their thoughts on this topic and offer suggestion in the comments.

arguments don’t work

there is no magical argument i can make to convince someone that tdd is a good idea. it is not a debate of logic, but rather debate of experience. we are not arguing here that 1 + 1 is 2, but rather that if you follow these practices than the result is subjectively better. since there is so much subjectivity in this, people need to experience tdd to understand its benefits. it is very hard to learn tdd by someone trying to learn it from a book. tdd is more like riding a bike. you can read books on how to do it, and you can have silly arguments with theorist that you cant ride a two wheel contraption because it is inherently unstable, but nothing makes them believers like living through the experience of learning to ride a bike. the first time you ride a bike it is a very clumsy experience, and i would argue that it takes hours of falling and uncertainty until you are better at it than walking. so don’t expect tdd to be any different. it is a skill that takes hours of practice to master. so don’t argue with anyone over your experiences, rather make others live through the same experience. have them come to the same conclusions by showing them.

make sure you know what you are talking about

nothing is worse, than someone selling me on something which they fully don’t understand. make sure you are reasonably good on tdd and have built a reasonable size application before you try to show someone else how to do it. imagine someone who has only seen others riding the bikes trying to teach someone else. my guess is that you will only get the person frustrated. for this reason built a small app in your free time with tdd. your first test will be the hardest, and at times you will think this is way more trouble than it is worth. but keep in mind that it is a new skill which you are learning, and it is the reason why you are struggling. you have been developing code for years the old way. what makes you think that you can pick up tdd over night? tdd makes you thing about tests first, something which you have never done. it will not come easy, but in time it will become second nature to you. for me that took about a year, before test first was a natural flow of things.

create a small project on show your boss how helpful tests are in refactorings

i cannot overstate the importance of learning the tdd on a brand new project without any deadlines. start something new in your free time and start building it with tdd. use it as a learning experience. you will discover all kinds of things about how to best write code. you will get a feel for tests which are helpful and tests which only get in the way. you will learn how to thing abut the problem from  test first perspective. you will realize how important it is for you to not get ahead of your tests. and finally you will discover that your code looks nothing like what you have envisioned. the code with tests looks different. than try to refactor something and you will see how some tests are in your way and some tests are helpful. you need to live through these experiences so that next time when you are test driving a class you can say, wait, this test looks like that other test i wrote and it was in my way when i was refactoring, but i know how i can write it differently so that it will be like this other test which turned out to be helpful. you can only have these debates in your head if you have built something with tdd.

if you try to bring tdd to an existing project, it may only fuel your bosses feeling that tdd is not useful. since you will be struggling a lot at the begging. again, it is a skill and it takes a while to develop.

tests help design

we all believe that good code is reusable code. for this reason most of us add all kinds of interfaces and abstraction in the name of reusability. but how much code have you actually reused compared to how much you have written. i say it is tiny fraction, very close to zero. one reason is that we only think we have reusable code. but tests are a great equalizer in this. tests force you to write reusable code so that you can use the class in production and in a test scenario. if you can’t write a test, it means that you don’t have a reusable code. if you write test first than it is very likely that the code will be reusable, after all you just used it in tests and in production. this is the single reason why tests first creates better design. on the other hand if you write code as you always have and  you will most likely end up with hard to reuse code. if you try to write a tests afterwards then at best the test is an afterthought which is hacked on top of the production code. this test is very unlikely to help you when you are refactoring since it will very likely be a false negative.

hardware folks have figured this out

did you know that average chip can have as much as 50% of its silicon dedicated to testing? why is it that every discipline out there takes testing seriously except software. i believe it is because of the apparent inexpensive nature of fixing bugs. a new rev of silicon is extremely expensive.  as a result most companies can only afford to rev it about 5 times. can you imagine writing code such that you are only allowed to run the production 5 times? yet the hardware folks cant imagine designing chips any other way. in software cost of another rev is close to zero. but it is not zero, and this is where people get into trouble. what is another build cost us? nothing, (almost) and so it becomes a death by thousand cuts. the more complicated the project the more likely it is that a fix in one location will cause a bug someplace else getting into an endless cycle of regressions. tests help here. but again it needs to be experienced.

if you get stuck, than spike

sometimes you just have no idea how to write tests first. there are a lot of reasons for this. so we revert to good old fashion hacking. there is no problem with that as long as after you learn by hacking, you go back and write the tests, or preferably throw it away and test drive it. we call this ’spike’. i get to do this quite a lot when faced with new technology or environment. just don’t let this become the way you develop software.

vote with your feet

if your boss is getting into micro-management of how you do things, and you have tried everything else to explain your position, you always have the right to vote with your feet. last time i checked, us software engineers are in high demand, so there is no reason to work for people which are being counterproductive.

what do you think?

what do the readers thing about how they could influence others in getting them to develop software with tests? please leave your comments so that we all con learn from each other…

from http://misko.hevery.com/