How to help team members adopt TDD?

[martin_sudmann]

I am scrum master in a team of mainly young developers. My goal is to install TDD as the standard approach to coding. The advantages are, as I see it:
- you don't produce more code than required to fulfil the requirements expressed by the tests
- you produce documentation through your tests
- compared to writing tests after the development, you win some time, because when you have finished the tests are already written
- your tests are not moulded after the code you wrote, but after the requirements
- you spend less time restarting your development server during development to test your work.

Might be I am off the line with this, but these are the benefits we saw so far in TDD.

The team has accepted to do unit testing as part of the definition of done and to check in tests with every development, but I have quite some difficulties to install TDD as a practice with one of them.
While there is already one doing everything the TDD way and the others are on their way to adopt it, there is one team member who tries to get out of the way of TDD.
The weird thing is, she has made a presentation to 50+ developers in the form of a coding dojo, showing how TDD works; but at the same time she tells me that she is not convinced of the benefits.

The coding dojo was my idea; I thought that preparing the session would allow her to gain enough inside into TDD to adopt it, and while demonstrating it to others she would be convinced herself as well.
But this didn't work, on the daily basis she still refuses to see its use. The dojo was more like an academic exercise to her, as it came out.
And it gets worse, now the team adopts TDD one by one, her resistance grows.

Anyone got a good idea how to allow her to discover the benefits of TDD at her own pace, without team pressure?
If she has her way, she will just continue to write her tests after the development.

Thanks,
Martin

[Kaleb Pederson-2]

On Tuesday 13 October 2009 01:22:30 pm martin_sudmann wrote:
> Anyone got a good idea how to allow her to discover the benefits of TDD at her own pace, without team pressure?
> If she has her way, she will just continue to write her tests after the development.

In order for someone to really appreciate TDD, they need to see what it buys them.

The main benefits that I see in TDD aren't on your list.  They are:

1) Improved design... my code is written to make it easy to test and read
2) Through constant repeated iteration, I reduce rework that I would have had to do had I failed to do TDD (<shameless plug>And which I recently a posted a blog entry about: http://www.kalebpederson.com/2009/10/beans-ping-pong-balls-and-priorities.html</shameless plug>).

You mentioned that she isn't convinced of the benefits.  Is she truly not convinced of the benefits or is she more concerned about the perceived costs of doing TDD?  Is she willing to come up with a "test" to see if the stated benefits of TDD are true?  Could the team come up with a test that everybody agreed upon?  If she did code reviews of TDD code and non-TDD code, would she see the differences or would it be attributed to developer skill?

Do your developers team together or do any pair programming?  If so, do you have a developer that can pair with her occasionally and show her?

You've asked a hard question. I'm interested in seeing other suggestions.

--Kaleb

Twitter - http://twitter.com/kalebpederson
Blog - http://kalebpederson.com

[Steven Smith-23]

I'd suggest having her pair with someone who's bought into the benefits of
TDD, and practice ping-pong coding where one of them writes the test and the
other makes it pass, then writes the next test.  It's a fun way to work and
makes it impossible to avoid the issue of writing the test first (though you
still have valid and valuable discussion about what next test to write).
If pairing isn't part of your culture, you might only try this for half an
hour or an hour at a time.

If there are bugs to be fixed, another good way to practice TDD is to
require that the bug be proven to exist via a test before it can be fixed.
 If you fix it first, there's no way to write such a test and be sure that
it ever failed (and thus that you did in fact fix the bug you thought you
did).  I find this approach is a good way to bring in TDD to groups that
don't use it already, since it's a very limited use case (bugs only).
 Branching out to general stories/features is then less difficult.

Steve

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis

On Tue, Oct 13, 2009 at 4:58 PM, Kaleb Pederson <kaleb.pederson@...>wrote:

>
>
> On Tuesday 13 October 2009 01:22:30 pm martin_sudmann wrote:
> > Anyone got a good idea how to allow her to discover the benefits of TDD
> at her own pace, without team pressure?
> > If she has her way, she will just continue to write her tests after the
> development.
>
> In order for someone to really appreciate TDD, they need to see what it
> buys them.
>
> The main benefits that I see in TDD aren't on your list. They are:
>
> 1) Improved design... my code is written to make it easy to test and read
> 2) Through constant repeated iteration, I reduce rework that I would have
> had to do had I failed to do TDD (<shameless plug>And which I recently a
> posted a blog entry about:
> http://www.kalebpederson.com/2009/10/beans-ping-pong-balls-and-priorities.html</shameless
> plug>).
>
> You mentioned that she isn't convinced of the benefits. Is she truly not
> convinced of the benefits or is she more concerned about the perceived costs
> of doing TDD? Is she willing to come up with a "test" to see if the stated
> benefits of TDD are true? Could the team come up with a test that everybody
> agreed upon? If she did code reviews of TDD code and non-TDD code, would she
> see the differences or would it be attributed to developer skill?
>
> Do your developers team together or do any pair programming? If so, do you
> have a developer that can pair with her occasionally and show her?
>
> You've asked a hard question. I'm interested in seeing other suggestions.
>
> --Kaleb
>
> Twitter - http://twitter.com/kalebpederson
> Blog - http://kalebpederson.com
>
>  
>

[Non-text portions of this message have been removed]

[Olof Bjarnason]

If you want practice problems, please visit the TDD list's site
"TDD-problems":

http://sites.google.com/site/tddproblems/

2009/10/13 martin_sudmann <martin_sudmann@...>

>
>
> I am scrum master in a team of mainly young developers. My goal is to
> install TDD as the standard approach to coding. The advantages are, as I see
> it:
> - you don't produce more code than required to fulfil the requirements
> expressed by the tests
> - you produce documentation through your tests
> - compared to writing tests after the development, you win some time,
> because when you have finished the tests are already written
> - your tests are not moulded after the code you wrote, but after the
> requirements
> - you spend less time restarting your development server during development
> to test your work.
>
> Might be I am off the line with this, but these are the benefits we saw so
> far in TDD.
>
> The team has accepted to do unit testing as part of the definition of done
> and to check in tests with every development, but I have quite some
> difficulties to install TDD as a practice with one of them.
> While there is already one doing everything the TDD way and the others are
> on their way to adopt it, there is one team member who tries to get out of
> the way of TDD.
> The weird thing is, she has made a presentation to 50+ developers in the
> form of a coding dojo, showing how TDD works; but at the same time she tells
> me that she is not convinced of the benefits.
>
> The coding dojo was my idea; I thought that preparing the session would
> allow her to gain enough inside into TDD to adopt it, and while
> demonstrating it to others she would be convinced herself as well.
> But this didn't work, on the daily basis she still refuses to see its use.
> The dojo was more like an academic exercise to her, as it came out.
> And it gets worse, now the team adopts TDD one by one, her resistance
> grows.
>
> Anyone got a good idea how to allow her to discover the benefits of TDD at
> her own pace, without team pressure?
> If she has her way, she will just continue to write her tests after the
> development.
>
> Thanks,
> Martin
>
>  
>

--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english


[Non-text portions of this message have been removed]

[Kaleb Pederson-2]

On Tuesday 13 October 2009 02:05:06 pm Steven Smith wrote:
> If there are bugs to be fixed, another good way to practice TDD is to
> require that the bug be proven to exist via a test before it can be fixed.
>  If you fix it first, there's no way to write such a test and be sure that
> it ever failed (and thus that you did in fact fix the bug you thought you
> did).  I find this approach is a good way to bring in TDD to groups that
> don't use it already, since it's a very limited use case (bugs only).
>  Branching out to general stories/features is then less difficult.

Good point Steve.

Also, after doing something like this for a while (on most brownfield projects), you'll also become quickly aware of the difference between good code and separation of concerns and highly coupled, dependency-heavy code.

If the code is really hard to work with, it might take something like Michael Feather's /Working Effectively with Legacy Code/ (http://bit.ly/8Xaql) to make it possible.

--Kaleb

Twitter - http://twitter.com/kalebpederson
Blog - http://kalebpederson.com

[Gishu P]

No easy answer :) You can't install TDD as a team-practice within a few
months. You could wrap it around a management-directive cudgel.. however the
team needs time to get their heads around it and get over Fowler's
improvement ravine
http://www.stevenmsmith.com/my-articles/article/the-satir-change-model.html
(The good news is resistance is a pre-cursor to adoption. The bad news is
that the march might end there itself)

Despite the din of the vociferous test-infected section, TDD is harder than
the old ways. Especially till you reach the same or higher level of
productivity than before. Let the team inspect their working model and come
up with solutions - let them make their own decisions (even if you apply
subtle steering comments to guide them) ;
Change is hard for many people.. getting a team onto a new practice is hard.
It depends on the composition of your team. You may also want to pick up a
copy of "Fearless Change". But by and large, you will have a specific
segment that actively repulse any attempts to switch from their old habits.
You can then only hope that the "adopters" section of your team outnumbers
the "laggards"/"skeptics" section. Don't waste your time getting the
skeptics on board... instead focus your efforts on the adopters and helping
them get productive. By this I don't mean give up on the laggards, if they
raise objective issues, discuss and apply counter-measures or dispel myths.
However I've seen some skeptics in my time and a large portion of their
dissent is made-up situations of 'why it wont work', without giving it a
fair try. Do not get caught up in subjective debate.


[Non-text portions of this message have been removed]

[Lance Walton]

--- In testdrivendevelopment@..., "martin_sudmann" <martin_sudmann@...> wrote:
>
> ...
> The team has accepted to do unit testing as part of the definition of done and to check in tests with every development, but I have quite some difficulties to install TDD as a practice with one of them.

Is she a part of the team or not? If she is, and the team wants to do it, why is she behaving as if she's not a part of the team? Or is it that the team has 'accepted' to do it because they're tired of arguing with someone (you) about it, and she is simply the most stubborn member of the team?

> The weird thing is, she has made a presentation to 50+ developers in the form of a coding dojo, showing how TDD works; but at the same time she tells me that she is not convinced of the benefits.

Maybe she has seen something the rest of us have not... Maybe in putting the presentation together she learned something that dissuaded her of the benefits.

> Anyone got a good idea how to allow her to discover the benefits of TDD at her own pace, without team pressure?

I think you answer your own question...

> If she has her way, she will just continue to write her tests after the development.

If you did not know how she was doing it, could you tell the difference in the result? You still get tested code. Does it not conform to the team's quality standards? How are you aware that she is not TDDing?

I ask these things as someone who believes in TDD.

>
> Thanks,
> Martin
>

[Lior Friedman]

Hi Martin,

>> Anyone got a good idea how to allow her to discover the benefits of TDD
at her own pace, without team pressure?

>I think you answer your own question...

>> If she has her way, she will just continue to write her tests after the
development.

>If you did not know how she was doing it, could you tell the difference in
the result? You still get tested code. Does it not conform to the team's
quality standards? How are you aware that >she is not TDDing?



I think that what he was trying to say that there might be no harm in
letting her not do TDD.

In fact as long as she produces high quality code and does not make other
follow her. It's probably be a better idea to invest your effort elsewhere.

 

if you still want to have a try at convincing her there might be two things
worth trying:

1)      Doing TDD does not take more effort than doing test after.

2)      Focus on the end result: high quality code covered well with a set
of automated test, and not on the technique to get there. Hopefully over
time she will recognize that TDD is the easiest way to achieve that.

 

I would however would love to hear how this turns out since I'm going to
face a very similar situation.

 

Lior Friedman

 



[Non-text portions of this message have been removed]

[Mark Levison-2]

Shameless plug - I wrote an article for InfoQ on this issue nearly a year
ago now: Making TDD Stick: Problems and Solutions for
Adopters<http://www.infoq.com/articles/levison-TDD-adoption-strategy>

Good Luck
Mark

On Tue, Oct 13, 2009 at 4:22 PM, martin_sudmann <martin_sudmann@...>wrote:

>
>
> I am scrum master in a team of mainly young developers. My goal is to
> install TDD as the standard approach to coding. The advantages are, as I see
> it:
> - you don't produce more code than required to fulfil the requirements
> expressed by the tests
> - you produce documentation through your tests
> - compared to writing tests after the development, you win some time,
> because when you have finished the tests are already written
> - your tests are not moulded after the code you wrote, but after the
> requirements
> - you spend less time restarting your development server during development
> to test your work.
>
> Might be I am off the line with this, but these are the benefits we saw so
> far in TDD.
>
> The team has accepted to do unit testing as part of the definition of done
> and to check in tests with every development, but I have quite some
> difficulties to install TDD as a practice with one of them.
> While there is already one doing everything the TDD way and the others are
> on their way to adopt it, there is one team member who tries to get out of
> the way of TDD.
> The weird thing is, she has made a presentation to 50+ developers in the
> form of a coding dojo, showing how TDD works; but at the same time she tells
> me that she is not convinced of the benefits.
>
> The coding dojo was my idea; I thought that preparing the session would
> allow her to gain enough inside into TDD to adopt it, and while
> demonstrating it to others she would be convinced herself as well.
> But this didn't work, on the daily basis she still refuses to see its use.
> The dojo was more like an academic exercise to her, as it came out.
> And it gets worse, now the team adopts TDD one by one, her resistance
> grows.
>
> Anyone got a good idea how to allow her to discover the benefits of TDD at
> her own pace, without team pressure?
> If she has her way, she will just continue to write her tests after the
> development.
>
> Thanks,
> Martin
>
>  
>

   *Mark Levison* | Founder and Consultant -
TheAgileConsortium<http://theagileconsortium.com/>| Agile
Editor @ InfoQ <http://www.infoq.com/about.jsp>
Blog <http://www.notesfromatooluser.com/> |
Twitter<http://twitter.com/mlevison>| Office: [phone]
Recent Entries: Agile Mailing Lists a
Survey<http://www.notesfromatooluser.com/2009/06/agile-mailing-lists.html%20>,
Do You Suspect You Have a Less than Productive Person on Your
Team?<http://www.notesfromatooluser.com/2009/01/do-you-suspect-you-have-a-less-than-productive-person-on-your-team.html>


[Non-text portions of this message have been removed]

[martin_sudmann]

Thanks for your answers!

Kaleb, I agree with your 2 points; they are important to me, too.

Steven, I like the ping-pong idea. Actually we are pairing quite a lot; this sounds like fun. Proving the bug to exist with a failing test is a good idea as well.
Actually there is another developer who is really enthusiastic about TDD, I'll try to make them do this together.

One big argument of hers is always the hard to test legacy code. I have to acknowledge that we own a lot of really bad old code with endless procedural methods; but this is one of the reasons I try to install TDD, to make new code more testable and slowly cut the old code into more testable pieces.

Until now I have been actively trying to get her trying new things out. This didn't work yet. Maybe I should really try to focus on the "white sheep" and hope that seeing the others evolve wakes her desire do like them. The only problem is that she has a low self esteem, so this might back-fire as well...


--- In testdrivendevelopment@..., Steven Smith <ssmith.lists@...> wrote:

>
> I'd suggest having her pair with someone who's bought into the benefits of
> TDD, and practice ping-pong coding where one of them writes the test and the
> other makes it pass, then writes the next test.  It's a fun way to work and
> makes it impossible to avoid the issue of writing the test first (though you
> still have valid and valuable discussion about what next test to write).
> If pairing isn't part of your culture, you might only try this for half an
> hour or an hour at a time.
>
> If there are bugs to be fixed, another good way to practice TDD is to
> require that the bug be proven to exist via a test before it can be fixed.
>  If you fix it first, there's no way to write such a test and be sure that
> it ever failed (and thus that you did in fact fix the bug you thought you
> did).  I find this approach is a good way to bring in TDD to groups that
> don't use it already, since it's a very limited use case (bugs only).
>  Branching out to general stories/features is then less difficult.
>
> Steve
>
> --
> Steve Smith
> http://SteveSmithBlog.com/
> http://twitter.com/ardalis
>
> On Tue, Oct 13, 2009 at 4:58 PM, Kaleb Pederson <kaleb.pederson@...>wrote:
>
> >
> >
> > On Tuesday 13 October 2009 01:22:30 pm martin_sudmann wrote:
> > > Anyone got a good idea how to allow her to discover the benefits of TDD
> > at her own pace, without team pressure?
> > > If she has her way, she will just continue to write her tests after the
> > development.
> >
> > In order for someone to really appreciate TDD, they need to see what it
> > buys them.
> >
> > The main benefits that I see in TDD aren't on your list. They are:
> >
> > 1) Improved design... my code is written to make it easy to test and read
> > 2) Through constant repeated iteration, I reduce rework that I would have
> > had to do had I failed to do TDD (<shameless plug>And which I recently a
> > posted a blog entry about:
> > http://www.kalebpederson.com/2009/10/beans-ping-pong-balls-and-priorities.html</shameless
> > plug>).
> >
> > You mentioned that she isn't convinced of the benefits. Is she truly not
> > convinced of the benefits or is she more concerned about the perceived costs
> > of doing TDD? Is she willing to come up with a "test" to see if the stated
> > benefits of TDD are true? Could the team come up with a test that everybody
> > agreed upon? If she did code reviews of TDD code and non-TDD code, would she
> > see the differences or would it be attributed to developer skill?
> >
> > Do your developers team together or do any pair programming? If so, do you
> > have a developer that can pair with her occasionally and show her?
> >
> > You've asked a hard question. I'm interested in seeing other suggestions.
> >
> > --Kaleb
> >
> > Twitter - http://twitter.com/kalebpederson
> > Blog - http://kalebpederson.com
> >
> >  
> >
>
>
> [Non-text portions of this message have been removed]
>

[Steven Smith-23]

Regarding legacy code, it can certainly be a drag on doing TDD.  Make sure
she (and everyone else on your team) has read Feathers' Working Effectively
with Legacy Code.  It's a great book whether you're working with legacy code
or not, but since you are, it's a must-read.
Steve


On Wed, Oct 14, 2009 at 4:52 PM, martin <martin_sudmann@...> wrote:

>
>
> Thanks for your answers!
>
> Kaleb, I agree with your 2 points; they are important to me, too.
>
> Steven, I like the ping-pong idea. Actually we are pairing quite a lot;
> this sounds like fun. Proving the bug to exist with a failing test is a good
> idea as well.
> Actually there is another developer who is really enthusiastic about TDD,
> I'll try to make them do this together.
>
> One big argument of hers is always the hard to test legacy code. I have to
> acknowledge that we own a lot of really bad old code with endless procedural
> methods; but this is one of the reasons I try to install TDD, to make new
> code more testable and slowly cut the old code into more testable pieces.
>
> Until now I have been actively trying to get her trying new things out.
> This didn't work yet. Maybe I should really try to focus on the "white
> sheep" and hope that seeing the others evolve wakes her desire do like them.
> The only problem is that she has a low self esteem, so this might back-fire
> as well...
>
>
> --- In testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>,
> Steven Smith <ssmith.lists@...> wrote:
> >
> > I'd suggest having her pair with someone who's bought into the benefits
> of
> > TDD, and practice ping-pong coding where one of them writes the test and
> the
> > other makes it pass, then writes the next test. It's a fun way to work
> and
> > makes it impossible to avoid the issue of writing the test first (though
> you
> > still have valid and valuable discussion about what next test to write).
> > If pairing isn't part of your culture, you might only try this for half
> an
> > hour or an hour at a time.
> >
> > If there are bugs to be fixed, another good way to practice TDD is to
> > require that the bug be proven to exist via a test before it can be
> fixed.
> > If you fix it first, there's no way to write such a test and be sure that
> > it ever failed (and thus that you did in fact fix the bug you thought you
> > did). I find this approach is a good way to bring in TDD to groups that
> > don't use it already, since it's a very limited use case (bugs only).
> > Branching out to general stories/features is then less difficult.
> >
> > Steve
> >
> > --
> > Steve Smith
> > http://SteveSmithBlog.com/
> > http://twitter.com/ardalis
> >
> > On Tue, Oct 13, 2009 at 4:58 PM, Kaleb Pederson <kaleb.pederson@
> ...>wrote:
>
> >
> > >
> > >
> > > On Tuesday 13 October 2009 01:22:30 pm martin_sudmann wrote:
> > > > Anyone got a good idea how to allow her to discover the benefits of
> TDD
> > > at her own pace, without team pressure?
> > > > If she has her way, she will just continue to write her tests after
> the
> > > development.
> > >
> > > In order for someone to really appreciate TDD, they need to see what it
> > > buys them.
> > >
> > > The main benefits that I see in TDD aren't on your list. They are:
> > >
> > > 1) Improved design... my code is written to make it easy to test and
> read
> > > 2) Through constant repeated iteration, I reduce rework that I would
> have
> > > had to do had I failed to do TDD (<shameless plug>And which I recently
> a
> > > posted a blog entry about:
> > >
> http://www.kalebpederson.com/2009/10/beans-ping-pong-balls-and-priorities.html
> </shameless
> > > plug>).
> > >
> > > You mentioned that she isn't convinced of the benefits. Is she truly
> not
> > > convinced of the benefits or is she more concerned about the perceived
> costs
> > > of doing TDD? Is she willing to come up with a "test" to see if the
> stated
> > > benefits of TDD are true? Could the team come up with a test that
> everybody
> > > agreed upon? If she did code reviews of TDD code and non-TDD code,
> would she
> > > see the differences or would it be attributed to developer skill?
> > >
> > > Do your developers team together or do any pair programming? If so, do
> you
> > > have a developer that can pair with her occasionally and show her?
> > >
> > > You've asked a hard question. I'm interested in seeing other
> suggestions.
> > >
> > > --Kaleb
> > >
> > > Twitter - http://twitter.com/kalebpederson
> > > Blog - http://kalebpederson.com
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>  
>

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis


[Non-text portions of this message have been removed]

[Donaldson, John (GEO)]

I'm not sure that selling TDD with legacy code is such a hard sell. It seems to me that green-field TDD is quite a hard sell because, at the end of a day of TDD you have less functional code than someone who just writes code with no tests. It only starts to pay off gradually. Whereas in the case of applying TDD to legacy code you are in a different situation. You have lots of functioning code but it's so hard to change - here the message of a small test and a small change sounds quite different. And at the end of a day you have some tests that you didn't have before and maybe a solid change or two.

But I certainly agree that getting to the first test in a legacy situation can be hard.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Steven Smith
Sent: 14 October 2009 23:36
To: testdrivendevelopment@...
Subject: Re: [TDD] How to help team members adopt TDD?

Regarding legacy code, it can certainly be a drag on doing TDD.  Make sure
she (and everyone else on your team) has read Feathers' Working Effectively
with Legacy Code.  It's a great book whether you're working with legacy code
or not, but since you are, it's a must-read.
Steve


On Wed, Oct 14, 2009 at 4:52 PM, martin <martin_sudmann@...> wrote:

>
>
> Thanks for your answers!
>
> Kaleb, I agree with your 2 points; they are important to me, too.
>
> Steven, I like the ping-pong idea. Actually we are pairing quite a lot;
> this sounds like fun. Proving the bug to exist with a failing test is a good
> idea as well.
> Actually there is another developer who is really enthusiastic about TDD,
> I'll try to make them do this together.
>
> One big argument of hers is always the hard to test legacy code. I have to
> acknowledge that we own a lot of really bad old code with endless procedural
> methods; but this is one of the reasons I try to install TDD, to make new
> code more testable and slowly cut the old code into more testable pieces.
>
> Until now I have been actively trying to get her trying new things out.
> This didn't work yet. Maybe I should really try to focus on the "white
> sheep" and hope that seeing the others evolve wakes her desire do like them.
> The only problem is that she has a low self esteem, so this might back-fire
> as well...
>
>
> --- In testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>,
> Steven Smith <ssmith.lists@...> wrote:
> >
> > I'd suggest having her pair with someone who's bought into the benefits
> of
> > TDD, and practice ping-pong coding where one of them writes the test and
> the
> > other makes it pass, then writes the next test. It's a fun way to work
> and
> > makes it impossible to avoid the issue of writing the test first (though
> you
> > still have valid and valuable discussion about what next test to write).
> > If pairing isn't part of your culture, you might only try this for half
> an
> > hour or an hour at a time.
> >
> > If there are bugs to be fixed, another good way to practice TDD is to
> > require that the bug be proven to exist via a test before it can be
> fixed.
> > If you fix it first, there's no way to write such a test and be sure that
> > it ever failed (and thus that you did in fact fix the bug you thought you
> > did). I find this approach is a good way to bring in TDD to groups that
> > don't use it already, since it's a very limited use case (bugs only).
> > Branching out to general stories/features is then less difficult.
> >
> > Steve
> >
> > --
> > Steve Smith
> > http://SteveSmithBlog.com/
> > http://twitter.com/ardalis
> >
> > On Tue, Oct 13, 2009 at 4:58 PM, Kaleb Pederson <kaleb.pederson@
> ...>wrote:
>
> >
> > >
> > >
> > > On Tuesday 13 October 2009 01:22:30 pm martin_sudmann wrote:
> > > > Anyone got a good idea how to allow her to discover the benefits of
> TDD
> > > at her own pace, without team pressure?
> > > > If she has her way, she will just continue to write her tests after
> the
> > > development.
> > >
> > > In order for someone to really appreciate TDD, they need to see what it
> > > buys them.
> > >
> > > The main benefits that I see in TDD aren't on your list. They are:
> > >
> > > 1) Improved design... my code is written to make it easy to test and
> read
> > > 2) Through constant repeated iteration, I reduce rework that I would
> have
> > > had to do had I failed to do TDD (<shameless plug>And which I recently
> a
> > > posted a blog entry about:
> > >
> http://www.kalebpederson.com/2009/10/beans-ping-pong-balls-and-priorities.html
> </shameless
> > > plug>).
> > >
> > > You mentioned that she isn't convinced of the benefits. Is she truly
> not
> > > convinced of the benefits or is she more concerned about the perceived
> costs
> > > of doing TDD? Is she willing to come up with a "test" to see if the
> stated
> > > benefits of TDD are true? Could the team come up with a test that
> everybody
> > > agreed upon? If she did code reviews of TDD code and non-TDD code,
> would she
> > > see the differences or would it be attributed to developer skill?
> > >
> > > Do your developers team together or do any pair programming? If so, do
> you
> > > have a developer that can pair with her occasionally and show her?
> > >
> > > You've asked a hard question. I'm interested in seeing other
> suggestions.
> > >
> > > --Kaleb
> > >
> > > Twitter - http://twitter.com/kalebpederson
> > > Blog - http://kalebpederson.com
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>  
>

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

[Manuel Klimek]

- How does she know that the tests fail when the code has a defect?
- How does she make sure her code is testable?
- How much rework does she do after writing the tests?

There are ways of working that produce good code without tdd, but there have
to be other practices to fill the gap, and I think the answers to those
questions might help.

Cheers,
/Manuel

On Oct 13, 2009 10:22 PM, "martin_sudmann" <martin_sudmann@...> wrote:



I am scrum master in a team of mainly young developers. My goal is to
install TDD as the standard approach to coding. The advantages are, as I see
it:
- you don't produce more code than required to fulfil the requirements
expressed by the tests
- you produce documentation through your tests
- compared to writing tests after the development, you win some time,
because when you have finished the tests are already written
- your tests are not moulded after the code you wrote, but after the
requirements
- you spend less time restarting your development server during development
to test your work.

Might be I am off the line with this, but these are the benefits we saw so
far in TDD.

The team has accepted to do unit testing as part of the definition of done
and to check in tests with every development, but I have quite some
difficulties to install TDD as a practice with one of them.
While there is already one doing everything the TDD way and the others are
on their way to adopt it, there is one team member who tries to get out of
the way of TDD.
The weird thing is, she has made a presentation to 50+ developers in the
form of a coding dojo, showing how TDD works; but at the same time she tells
me that she is not convinced of the benefits.

The coding dojo was my idea; I thought that preparing the session would
allow her to gain enough inside into TDD to adopt it, and while
demonstrating it to others she would be convinced herself as well.
But this didn't work, on the daily basis she still refuses to see its use.
The dojo was more like an academic exercise to her, as it came out.
And it gets worse, now the team adopts TDD one by one, her resistance grows.

Anyone got a good idea how to allow her to discover the benefits of TDD at
her own pace, without team pressure?
If she has her way, she will just continue to write her tests after the
development.

Thanks,
Martin

 


[Non-text portions of this message have been removed]

[Carfield Yim-2]

Nice observation

On 10/15/09, Donaldson, John (GEO) <john.m.donaldson@...> wrote:

> I'm not sure that selling TDD with legacy code is such a hard sell. It seems
> to me that green-field TDD is quite a hard sell because, at the end of a day
> of TDD you have less functional code than someone who just writes code with
> no tests. It only starts to pay off gradually. Whereas in the case of
> applying TDD to legacy code you are in a different situation. You have lots
> of functioning code but it's so hard to change - here the message of a small
> test and a small change sounds quite different. And at the end of a day you
> have some tests that you didn't have before and maybe a solid change or two.
>
> But I certainly agree that getting to the first test in a legacy situation
> can be hard.
>
> John D.
>
> -----Original Message-----
> From: testdrivendevelopment@...
> [mailto:testdrivendevelopment@...] On Behalf Of Steven Smith
> Sent: 14 October 2009 23:36
> To: testdrivendevelopment@...
> Subject: Re: [TDD] How to help team members adopt TDD?
>
> Regarding legacy code, it can certainly be a drag on doing TDD.  Make sure
> she (and everyone else on your team) has read Feathers' Working Effectively
> with Legacy Code.  It's a great book whether you're working with legacy code
> or not, but since you are, it's a must-read.
> Steve
>
>
> On Wed, Oct 14, 2009 at 4:52 PM, martin <martin_sudmann@...> wrote:
>
>>
>>
>> Thanks for your answers!
>>
>> Kaleb, I agree with your 2 points; they are important to me, too.
>>
>> Steven, I like the ping-pong idea. Actually we are pairing quite a lot;
>> this sounds like fun. Proving the bug to exist with a failing test is a
>> good
>> idea as well.
>> Actually there is another developer who is really enthusiastic about TDD,
>> I'll try to make them do this together.
>>
>> One big argument of hers is always the hard to test legacy code. I have to
>> acknowledge that we own a lot of really bad old code with endless
>> procedural
>> methods; but this is one of the reasons I try to install TDD, to make new
>> code more testable and slowly cut the old code into more testable pieces.
>>
>> Until now I have been actively trying to get her trying new things out.
>> This didn't work yet. Maybe I should really try to focus on the "white
>> sheep" and hope that seeing the others evolve wakes her desire do like
>> them.
>> The only problem is that she has a low self esteem, so this might
>> back-fire
>> as well...
>>
>>
>> --- In
>> testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>,
>> Steven Smith <ssmith.lists@...> wrote:
>> >
>> > I'd suggest having her pair with someone who's bought into the benefits
>> of
>> > TDD, and practice ping-pong coding where one of them writes the test and
>> the
>> > other makes it pass, then writes the next test. It's a fun way to work
>> and
>> > makes it impossible to avoid the issue of writing the test first (though
>> you
>> > still have valid and valuable discussion about what next test to write).
>> > If pairing isn't part of your culture, you might only try this for half
>> an
>> > hour or an hour at a time.
>> >
>> > If there are bugs to be fixed, another good way to practice TDD is to
>> > require that the bug be proven to exist via a test before it can be
>> fixed.
>> > If you fix it first, there's no way to write such a test and be sure
>> > that
>> > it ever failed (and thus that you did in fact fix the bug you thought
>> > you
>> > did). I find this approach is a good way to bring in TDD to groups that
>> > don't use it already, since it's a very limited use case (bugs only).
>> > Branching out to general stories/features is then less difficult.
>> >
>> > Steve
>> >
>> > --
>> > Steve Smith
>> > http://SteveSmithBlog.com/
>> > http://twitter.com/ardalis
>> >
>> > On Tue, Oct 13, 2009 at 4:58 PM, Kaleb Pederson <kaleb.pederson@
>> ...>wrote:
>>
>> >
>> > >
>> > >
>> > > On Tuesday 13 October 2009 01:22:30 pm martin_sudmann wrote:
>> > > > Anyone got a good idea how to allow her to discover the benefits of
>> TDD
>> > > at her own pace, without team pressure?
>> > > > If she has her way, she will just continue to write her tests after
>> the
>> > > development.
>> > >
>> > > In order for someone to really appreciate TDD, they need to see what
>> > > it
>> > > buys them.
>> > >
>> > > The main benefits that I see in TDD aren't on your list. They are:
>> > >
>> > > 1) Improved design... my code is written to make it easy to test and
>> read
>> > > 2) Through constant repeated iteration, I reduce rework that I would
>> have
>> > > had to do had I failed to do TDD (<shameless plug>And which I recently
>> a
>> > > posted a blog entry about:
>> > >
>> http://www.kalebpederson.com/2009/10/beans-ping-pong-balls-and-priorities.html
>> </shameless
>> > > plug>).
>> > >
>> > > You mentioned that she isn't convinced of the benefits. Is she truly
>> not
>> > > convinced of the benefits or is she more concerned about the perceived
>> costs
>> > > of doing TDD? Is she willing to come up with a "test" to see if the
>> stated
>> > > benefits of TDD are true? Could the team come up with a test that
>> everybody
>> > > agreed upon? If she did code reviews of TDD code and non-TDD code,
>> would she
>> > > see the differences or would it be attributed to developer skill?
>> > >
>> > > Do your developers team together or do any pair programming? If so, do
>> you
>> > > have a developer that can pair with her occasionally and show her?
>> > >
>> > > You've asked a hard question. I'm interested in seeing other
>> suggestions.
>> > >
>> > > --Kaleb
>> > >
>> > > Twitter - http://twitter.com/kalebpederson
>> > > Blog - http://kalebpederson.com
>> > >
>> > >
>> > >
>> >
>> >
>> > [Non-text portions of this message have been removed]
>> >
>>
>>
>>
>
>
>
> --
> Steve Smith
> http://SteveSmithBlog.com/
> http://twitter.com/ardalis
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Christian Hargraves-5]

Hi Martin,

I posted a long blog entry based on my previous experiences of
test-infecting teams (as a developer).
http://grizzlylessons.blogspot.com/2009/06/test-infecting-development-team.html
.
It may sound simple, but it's the approach that has worked for me the best
several times.

Some ideas from the article are:

- Test infect one person on the team (sounds like you did this and more
already). The idea is to make yourself reproducible and therefore the method
reproducible.
- Mentor this person in people skills specific to empathy and resolving
concerns. Note not every concern needs to be resolved. In many cases, just
admiting the conern is valid is good enough.
- Don't make TDD a personal thing. TDD is a tool for developers. Developers
just need to see it as so.
- When someone is having a hard time adopting TDD, find out why and let the
team resolve that concern or admit it is a problem. Reflection workshops
worked best for me. It was more of an organic thing and I get to step
outside of the light and let the rest of the rest of the team talk about it.
- In general, people learn better from their peers than from a manager
(there are all sorts of clubs and organizations outside of software that
have proven this over and over again).
- Support everyone on the team in learning TDD. This means to show empathy.
After all, nothing is perfect; not even TDD. People simply need to see that
the strengths outweigh the weakeneses by themselves.
- Don't make others feel bad because they aren't doing TDD. Generally,
avoid playing the pride game as, in many cases, pride gets in the way of
adopting change.

I have test-infected several people simply by showing empathy towards the
weaknesses pointed out.

As far as doing TDD against a legacy system, as several people have already
noted, it can be hard. This is one of the areas where support is crucial.
There are skills that once learned, can greatly help when doing TDD against
legacy code. However, without that support and those skills doing so can
seem futile.

Regards,
Christian
On Wed, Oct 14, 2009 at 2:52 PM, martin <martin_sudmann@...> wrote:

>
>
> Thanks for your answers!
>
> Kaleb, I agree with your 2 points; they are important to me, too.
>
> Steven, I like the ping-pong idea. Actually we are pairing quite a lot;
> this sounds like fun. Proving the bug to exist with a failing test is a good
> idea as well.
> Actually there is another developer who is really enthusiastic about TDD,
> I'll try to make them do this together.
>
> One big argument of hers is always the hard to test legacy code. I have to
> acknowledge that we own a lot of really bad old code with endless procedural
> methods; but this is one of the reasons I try to install TDD, to make new
> code more testable and slowly cut the old code into more testable pieces.
>
> Until now I have been actively trying to get her trying new things out.
> This didn't work yet. Maybe I should really try to focus on the "white
> sheep" and hope that seeing the others evolve wakes her desire do like them.
> The only problem is that she has a low self esteem, so this might back-fire
> as well...
>
>
> --- In testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>,
> Steven Smith <ssmith.lists@...> wrote:
> >
> > I'd suggest having her pair with someone who's bought into the benefits
> of
> > TDD, and practice ping-pong coding where one of them writes the test and
> the
> > other makes it pass, then writes the next test. It's a fun way to work
> and
> > makes it impossible to avoid the issue of writing the test first (though
> you
> > still have valid and valuable discussion about what next test to write).
> > If pairing isn't part of your culture, you might only try this for half
> an
> > hour or an hour at a time.
> >
> > If there are bugs to be fixed, another good way to practice TDD is to
> > require that the bug be proven to exist via a test before it can be
> fixed.
> > If you fix it first, there's no way to write such a test and be sure that
> > it ever failed (and thus that you did in fact fix the bug you thought you
> > did). I find this approach is a good way to bring in TDD to groups that
> > don't use it already, since it's a very limited use case (bugs only).
> > Branching out to general stories/features is then less difficult.
> >
> > Steve
> >
> > --
> > Steve Smith
> > http://SteveSmithBlog.com/ <http://stevesmithblog.com/>
> > http://twitter.com/ardalis
> >
> > On Tue, Oct 13, 2009 at 4:58 PM, Kaleb Pederson <kaleb.pederson@...>wrote:
>
>
> >
> > >
> > >
> > > On Tuesday 13 October 2009 01:22:30 pm martin_sudmann wrote:
> > > > Anyone got a good idea how to allow her to discover the benefits of
> TDD
> > > at her own pace, without team pressure?
> > > > If she has her way, she will just continue to write her tests after
> the
> > > development.
> > >
> > > In order for someone to really appreciate TDD, they need to see what it
> > > buys them.
> > >
> > > The main benefits that I see in TDD aren't on your list. They are:
> > >
> > > 1) Improved design... my code is written to make it easy to test and
> read
> > > 2) Through constant repeated iteration, I reduce rework that I would
> have
> > > had to do had I failed to do TDD (<shameless plug>And which I recently
> a
> > > posted a blog entry about:
> > >
> http://www.kalebpederson.com/2009/10/beans-ping-pong-balls-and-priorities.html
> </shameless
> > > plug>).
> > >
> > > You mentioned that she isn't convinced of the benefits. Is she truly
> not
> > > convinced of the benefits or is she more concerned about the perceived
> costs
> > > of doing TDD? Is she willing to come up with a "test" to see if the
> stated
> > > benefits of TDD are true? Could the team come up with a test that
> everybody
> > > agreed upon? If she did code reviews of TDD code and non-TDD code,
> would she
> > > see the differences or would it be attributed to developer skill?
> > >
> > > Do your developers team together or do any pair programming? If so, do
> you
> > > have a developer that can pair with her occasionally and show her?
> > >
> > > You've asked a hard question. I'm interested in seeing other
> suggestions.
> > >
> > > --Kaleb
> > >
> > > Twitter - http://twitter.com/kalebpederson
> > > Blog - http://kalebpederson.com
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>  
>

[Non-text portions of this message have been removed]

[Steve Freeman-4]

This is beginning to sound as if it's not really about TDD.

Perhaps it's about her view of herself as an expert coder, or her autonomy over how she does her work? What does she see that the others don't? Does she not respect the opinions of her team? Is she feeling frustrated because she can't get stuff done with TDD, and just wants to get on and write code? -- and what does that say about the delivery culture? Does she not agree with the benefits that you (and the others?) perceive?

S.

> On Oct 13, 2009 10:22 PM, "martin_sudmann" <martin_sudmann@...> wrote:
> [...]
> Might be I am off the line with this, but these are the benefits we saw so
> far in TDD.
>
> The team has accepted to do unit testing as part of the definition of done
> and to check in tests with every development, but I have quite some
> difficulties to install TDD as a practice with one of them.
> While there is already one doing everything the TDD way and the others are
> on their way to adopt it, there is one team member who tries to get out of
> the way of TDD.
> The weird thing is, she has made a presentation to 50+ developers in the
> form of a coding dojo, showing how TDD works; but at the same time she tells
> me that she is not convinced of the benefits.
>
> The coding dojo was my idea; I thought that preparing the session would
> allow her to gain enough inside into TDD to adopt it, and while
> demonstrating it to others she would be convinced herself as well.
> But this didn't work, on the daily basis she still refuses to see its use.
> The dojo was more like an academic exercise to her, as it came out.
> And it gets worse, now the team adopts TDD one by one, her resistance grows.
>
> Anyone got a good idea how to allow her to discover the benefits of TDD at
> her own pace, without team pressure?
> If she has her way, she will just continue to write her tests after the
> development.

Steve Freeman
http://www.mockobjects.com
http://www.growing-object-oriented-software.com

Winner of the Agile Alliance Gordon Pask award 2006

[Mike Emeigh]

On Tue, Nov 10, 2009 at 12:10 PM, Steve Freeman wrote:
>
>
>
> This is beginning to sound as if it's not really about TDD.
>
> Perhaps it's about her view of herself as an expert coder, or her autonomy over how she does her work? What does she see that
> the others don't? Does she not respect the opinions of her team? Is she feeling frustrated because she can't get stuff done with
> TDD, and just wants to get on and write code? -- and what does that say about the delivery culture? Does she not agree with the
> benefits that you (and the others?) perceive?

Other questions: Are there any issues with the quality of her
delivered code and/or tests? If there are not, then why does your team
want her to use a method with which she is (for whatever reason)
uncomfortable? As long as she is delivering working software (and
tests along with it, which it sounds as though she is), why does it
matter to your team what method she is using to deliver that working
software and tests?

Now if she's NOT delivering working software and tests in a timely
manner - as your team defines working software and tests, that is -
then the team needs to take a harder look at what she is doing. If she
IS delivering working software and tests but in a way that causes
unnecessary friction within the team, then the team needs to take a
look at that as well. But if she's delivering the product that the
team needs from her when the team needs it, I personally wouldn't get
too hung up over the specific method by which it's created.
--
Mike Emeigh
MWE55inNC@...

"Our brains, for all their wonders, identify the following four things
as being very bad for survival: Standing alone, in open territory with
no place to hide, without a weapon, in front of a large crowd of
creatures staring at you"

-- Scott Berkun, about why people fear public speaking

[martin_sudmann]

This has been about how to help people *adopt* TDD from the beginning, not about TDD itself.
The start point was that I wanted to have everybody on the team tried TDD at least twice before adopting or rejecting it. The developer in question rejected it before having tried it even once.

Her work was and is OK, complete with unit tests and all, only her code is not very modular and she doesn't have the reflexes that come naturally when you TDD your code. It's more like she modifies her code later in order to be able to test it. This is waste in my opinion.
Another aspect is, that for a team that is in the process of adopting a new technique it is disturbing to hear someone always say how she cannot see the use of that technique, how it isn't applicable to the code she is writing right now and so on.

But I think she will go at least through the "try it twice" phase (she starts to be a bit less opposed by now); if she rejects it after that is OK for me. I would still hope that team dynamics will do the trick in the end, though.

If you are interested, I will post the outcome here, let's say at the end of the year.

Thanks for all your help!
Martin

--- In testdrivendevelopment@..., Mike Emeigh <mwe55innc@...> wrote:

>
> On Tue, Nov 10, 2009 at 12:10 PM, Steve Freeman wrote:
> >
> >
> >
> > This is beginning to sound as if it's not really about TDD.
> >
> > Perhaps it's about her view of herself as an expert coder, or her autonomy over how she does her work? What does she see that
> > the others don't? Does she not respect the opinions of her team? Is she feeling frustrated because she can't get stuff done with
> > TDD, and just wants to get on and write code? -- and what does that say about the delivery culture? Does she not agree with the
> > benefits that you (and the others?) perceive?
>
> Other questions: Are there any issues with the quality of her
> delivered code and/or tests? If there are not, then why does your team
> want her to use a method with which she is (for whatever reason)
> uncomfortable? As long as she is delivering working software (and
> tests along with it, which it sounds as though she is), why does it
> matter to your team what method she is using to deliver that working
> software and tests?
>
> Now if she's NOT delivering working software and tests in a timely
> manner - as your team defines working software and tests, that is -
> then the team needs to take a harder look at what she is doing. If she
> IS delivering working software and tests but in a way that causes
> unnecessary friction within the team, then the team needs to take a
> look at that as well. But if she's delivering the product that the
> team needs from her when the team needs it, I personally wouldn't get
> too hung up over the specific method by which it's created.
> --
> Mike Emeigh
> MWE55inNC@...
>
> "Our brains, for all their wonders, identify the following four things
> as being very bad for survival: Standing alone, in open territory with
> no place to hide, without a weapon, in front of a large crowd of
> creatures staring at you"
>
> -- Scott Berkun, about why people fear public speaking
>

[Lior Friedman]

Here's one for you:

http://weblogs.asp.net/rosherove/archive/2009/11/12/test-driven-design-wille
d-vs-forced-designs.aspx

 

I brought it here because no matter where you stand the discussion is always
worthwhile in my opinion

 

 

Lior Friedman
Blog  -  <http://imistaken.blogspot.com/> http://imistaken.blogspot.com

 

 



[Non-text portions of this message have been removed]

[David Tchepak]

Hi Lior,

I really enjoyed your response to Roy's post. I don't agree that
TypeMock is evil, will cause bad design, or will injure innocent
kittens. However I also disagree that the feedback given by
proxy-based mocking tools is useless. I feel the tool limitations Roy
mentions in this case are more limitations of the languages they proxy
over, and as such they end up providing feedback when your design
won't change easily using your language/framework of choice.

Some people like this feedback, others don't want it and/or don't need
it. In the end it comes down to personal preference -- good design
will depend on the individual, not the tools.

If you'd like to read my full response you can stop by my blog:
http://www.davesquared.net/2009/11/impact-of-mocking-framework-limitations.html

Regards,
David

On Mon, Nov 16, 2009 at 6:56 PM, Lior Friedman <lfriedmal@...> wrote:

>
>
>
> Here's one for you:
>
> http://weblogs.asp.net/rosherove/archive/2009/11/12/test-driven-design-wille
> d-vs-forced-designs.aspx
>
> I brought it here because no matter where you stand the discussion is always
> worthwhile in my opinion
>
> Lior Friedman
> Blog - <http://imistaken.blogspot.com/> http://imistaken.blogspot.com
>
> [Non-text portions of this message have been removed]
>
>