RFC: Need volunteers to review content for a TDD workshop

[Gishu P]

The slides for my talk is shared here
http://docs.google.com/present/view?id=dcx49m86_22f2n8txcm

My motivation behind this was : "If you had just 6-8 hrs to sell and give a
rolling start on TDD to an audience (mixed expertise level)..."
I've collated whatever I could think of and recollect from all the various
books that I've read till now.

There also be 2 coding exercises in between where everyone gets some
hands-on time with TDD.

I'd like some eyeballs to spot
 - mistakes
 - better ways to rephrase / shorten something
 - omissions
- common questions / problems

I couldn't collate a FAQ list (ran out of time). If someone would like to
pitch in, I'd be happy to share access to the google doc. Just mail me your
google id (my email address is in the last slide)

Thanks
Gishu


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

[Carlo Bottiglieri]

Hello Gishu.
Very dense. I liked it.
Just three quick suggestions :

- in the slides I read that (and I get the feeling that) refactoring
means "remove duplication". If I were asked (and I was asked) I would
indeed agree that one can trace back almost any design issue to some
kind of knowledge duplication, yet it might be misleading to just say
that, I suggest you make sure that you are very clear on just how
broad a scope the refactoring phase entails.

- I would add Koskela's book to the list of resources.

- I see that you group all of the design smells from Uncle Bob's book
in one slide, and similarly you group all design principles. I would
advise against this. Last time I had to go over those it took me 5 to
10 minutes each, just to explain them quickly, not in depth, just what
was strictly required to make them pass through.
Thus I would extend the number of slides and provide meaningful images
for each of the design smells and for each of the design principles,
otherwise you risk to have the audience stare at the same grey slide
for the better part of an hour, or, inversely, to drift too quickly
through those concepts, which is dangerous.

On Thu, Oct 1, 2009 at 12:54 PM, Gishu Pillai <gishu.pillai@...> wrote:

> The slides for my talk is shared here
> http://docs.google.com/present/view?id=dcx49m86_22f2n8txcm
>
> My motivation behind this was : "If you had just 6-8 hrs to sell and give a
> rolling start on TDD to an audience (mixed expertise level)..."
> I've collated whatever I could think of and recollect from all the various
> books that I've read till now.
>
> There also be 2 coding exercises in between where everyone gets some
> hands-on time with TDD.
>
> I'd like some eyeballs to spot
>  - mistakes
>  - better ways to rephrase / shorten something
>  - omissions
> - common questions / problems
>
> I couldn't collate a FAQ list (ran out of time). If someone would like to
> pitch in, I'd be happy to share access to the google doc. Just mail me your
> google id (my email address is in the last slide)
>
> Thanks
> Gishu
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[pete-113]

On Thu, October 1, 2009 06:54, Gishu Pillai wrote:

> The slides for my talk is shared here
> http://docs.google.com/present/view?id=dcx49m86_22f2n8txcm
>
> My motivation behind this was : "If you had just 6-8 hrs to sell and give
> a rolling start on TDD to an audience (mixed expertise level)..."
> I've collated whatever I could think of and recollect from all the various
> books that I've read till now.
>
> There also be 2 coding exercises in between where everyone gets some
> hands-on time with TDD.
>
> I'd like some eyeballs to spot
>  - mistakes
>  - better ways to rephrase / shorten something
>  - omissions
> - common questions / problems
>
> I couldn't collate a FAQ list (ran out of time). If someone would like to
> pitch in, I'd be happy to share access to the google doc. Just mail me
> your google id (my email address is in the last slide)
>
> Thanks
> Gishu
>

Here is some quick feedback.

Slide 2:  Turn "BDUF" into a hotlink.

Slide 4:  The picture is fuzzy (on my 1280x1024 monitor)

Slide 9:  Identify the tools shown in the two pictures.

Slide 10: What about JMock?

Slide 15: Turn "TDD Anti-patterns" into a hotlink


Pete

[Donaldson, John (GEO)]

Gishu,

Wow - first of all - good job - you hit all the main topics as far as I can see.

But...
I usually work on a rule of thumb of 2 minutes per slide, and your slides are going to take *much* longer than that.
I`d expand several of the slides (mocks+DI, patterns, principals, etc) into many slides.
The problem with that is that then you realize that 6 hours (including hands-on) is not going to fit.

(And I don't think you mentioned FIT by the way, or refactoring tools or IDEs that help).

So, I'd be left with reduce the content (but provide pointers), or stretch out to 2 days.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Gishu Pillai
Sent: 01 October 2009 12:55
To: testdrivendevelopment@...
Subject: [TDD] RFC: Need volunteers to review content for a TDD workshop

The slides for my talk is shared here
http://docs.google.com/present/view?id=dcx49m86_22f2n8txcm

My motivation behind this was : "If you had just 6-8 hrs to sell and give a
rolling start on TDD to an audience (mixed expertise level)..."
I've collated whatever I could think of and recollect from all the various
books that I've read till now.

There also be 2 coding exercises in between where everyone gets some
hands-on time with TDD.

I'd like some eyeballs to spot
 - mistakes
 - better ways to rephrase / shorten something
 - omissions
- common questions / problems

I couldn't collate a FAQ list (ran out of time). If someone would like to
pitch in, I'd be happy to share access to the google doc. Just mail me your
google id (my email address is in the last slide)

Thanks
Gishu


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



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

Yahoo! Groups Links

[Olof Bjarnason]

I think your presentation rocks - but you will not be able to get all point
across in one mere day.

I tried running half-aday presentation/handson (much like you), and then it
was only TDD without any SOLID or DRY, not to mention MVP or DI/mocks. While
I can blame some of the failure (no one picked up TDD) to my relatively
fresh look at TDD then (had done 6 months of TDD), it was also too short
time lapse.

The information you've compiled takes years to appreciate. It's like you're
presenting multi-variate calculus to folks who don't know how to solve 2nd
order equations yet! :)

2009/10/1 Gishu Pillai <gishu.pillai@...>

>
>
> The slides for my talk is shared here
> http://docs.google.com/present/view?id=dcx49m86_22f2n8txcm
>
> My motivation behind this was : "If you had just 6-8 hrs to sell and give a
> rolling start on TDD to an audience (mixed expertise level)..."
> I've collated whatever I could think of and recollect from all the various
> books that I've read till now.
>
> There also be 2 coding exercises in between where everyone gets some
> hands-on time with TDD.
>
> I'd like some eyeballs to spot
> - mistakes
> - better ways to rephrase / shorten something
> - omissions
> - common questions / problems
>
> I couldn't collate a FAQ list (ran out of time). If someone would like to
> pitch in, I'd be happy to share access to the google doc. Just mail me your
> google id (my email address is in the last slide)
>
> Thanks
> Gishu
>
> [Non-text portions of this message have been removed]
>
>  
>

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


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

[Charlie Poole-4]

Hi John,

> Wow - first of all - good job - you hit all the main topics
> as far as I can see.

Agreed.

> But...
> I usually work on a rule of thumb of 2 minutes per slide, and
> your slides are going to take *much* longer than that.

In the usual "bullet point" style, I use the same guideline. But
since I read "Beyond Bullet Points" I tend to try to talk more
about each slide - and not have bullet points.

I've attended a day-long class by Ward Cunningham, which had
about 20 slides and it was - as you may imagine - quite good.

So, I think the slide count is up to the presenter.

However. I a slide is going to stay up a long time, while
the presenter speaks or exercises go on, I would tend to put
less info on one slide - perhaps a single point and accompanying
graphics.

> I`d expand several of the slides (mocks+DI, patterns,
> principals, etc) into many slides.

Yes - many of the slides could be split.

> The problem with that is that then you realize that 6 hours
> (including hands-on) is not going to fit.
>
> (And I don't think you mentioned FIT by the way, or
> refactoring tools or IDEs that help).

I'd include refactoring in a TDD presentatin but not FIT.
But of course there are different ways to slice it.
 
> So, I'd be left with reduce the content (but provide
> pointers), or stretch out to 2 days.

It's tough. My shortest hands-on TDD class is 2 days and
doesn't cover GUI. But it's possible to do highlights if
you carefully select the material. That's what I've done,
for example, when presenting at some conferences.

Charlie
 

> John D.
>
> -----Original Message-----
> From: testdrivendevelopment@...
> [mailto:testdrivendevelopment@...] On Behalf Of
> Gishu Pillai
> Sent: 01 October 2009 12:55
> To: testdrivendevelopment@...
> Subject: [TDD] RFC: Need volunteers to review content for a
> TDD workshop
>
> The slides for my talk is shared here
> http://docs.google.com/present/view?id=dcx49m86_22f2n8txcm
>
> My motivation behind this was : "If you had just 6-8 hrs to
> sell and give a rolling start on TDD to an audience (mixed
> expertise level)..."
> I've collated whatever I could think of and recollect from
> all the various books that I've read till now.
>
> There also be 2 coding exercises in between where everyone
> gets some hands-on time with TDD.
>
> I'd like some eyeballs to spot
>  - mistakes
>  - better ways to rephrase / shorten something
>  - omissions
> - common questions / problems
>
> I couldn't collate a FAQ list (ran out of time). If someone
> would like to pitch in, I'd be happy to share access to the
> google doc. Just mail me your google id (my email address is
> in the last slide)
>
> Thanks
> Gishu
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Charlie Poole-4]

Hi Gishu,

It's a great effort with all the right stuff. I'll get to
the suggestions now. :-)

1) I think you have too much material for the time if
your objective is to teach TDD. I do Gui testing on
the third day of my TDD class.

2) If your goal is to inspire/motivate/convince rather
than teach, then you may not need all the material. Ask
yourself what factors would lead this particular audience
to decide in favor of trying TDD and *only* include that
material.

3) If some material is included because you anticipate
objections, wait till people raise them - of course you
have to allow time for that. You can still prepare the
material that answers common objections but don't bring
it out until they are raised.

4) Split up your material into more slides. For example,
slide 7 "covers" seven principles of design in one slide.
Put them on separate slides and consider adding good and
bad examples to illustrate.

5) On the google site, your text doesn't it well on the
page - make sure it looks OK in your original presentation.

6) I like the slides that have graphical elements. Try
for more of them.

In general, I suggest that you ruthlessly cut material
until it fits into the allotted time *easily* even after
allowing for hands-on exercises and Q&A sessions.

You can give out a handout with the material you cut in
addition to what you present. Getting "extra" stuff
always impresses people.

Again - it's great work but may be a little too much
to do in such a short time.

Charlie

> -----Original Message-----
> From: testdrivendevelopment@...
> [mailto:testdrivendevelopment@...] On Behalf Of
> Gishu Pillai
> Sent: Thursday, October 01, 2009 3:55 AM
> To: testdrivendevelopment@...
> Subject: [TDD] RFC: Need volunteers to review content for a
> TDD workshop
>
> The slides for my talk is shared here
> http://docs.google.com/present/view?id=dcx49m86_22f2n8txcm
>
> My motivation behind this was : "If you had just 6-8 hrs to
> sell and give a rolling start on TDD to an audience (mixed
> expertise level)..."
> I've collated whatever I could think of and recollect from
> all the various books that I've read till now.
>
> There also be 2 coding exercises in between where everyone
> gets some hands-on time with TDD.
>
> I'd like some eyeballs to spot
>  - mistakes
>  - better ways to rephrase / shorten something
>  - omissions
> - common questions / problems
>
> I couldn't collate a FAQ list (ran out of time). If someone
> would like to pitch in, I'd be happy to share access to the
> google doc. Just mail me your google id (my email address is
> in the last slide)
>
> Thanks
> Gishu
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Gishu P]

@Carlo
- Agreed, will rephrase to indicate refactoring not always = remove
duplication... although its a 80% case
- Koskela's book - Haven't read it yet.. Will make a note of that. The first
batch of attendees have a .net desktop app background.. but I have a Java
group attending in the future. I wanted that slide to be the absolute
minimal set of must-read books ; past history indicates reading doesn't come
easy to a majority of programmers :)

@John, Carlo and Charlie
- A clear sign that compressing SOLID is a near-miss. Thanks for pointing
that out. My original take was to switch to a whiteboard, draw and talk with
the audience... (not in 2 min by a long shot); However I agree that this
needs more time and emphasis ; I guess just my mental block of someone
starting with a presentation that says 1/78 at the bottom right. Will get to
work on splitting atleast the SOLID priniciples out.
- I have a 20% confidence level of getting all this done in 1 day. I guess
will have to extend this to 2 days to avoid the audience tuning off with
info overload ; + they'll take their time to make and recover from mistakes
in the coding exercises, ask questions, et. all. I'm getting them to try
pairing as well for this so .. point noted. Have to do the right thing and
make it a 2-day workshop; Better for everyone concerned.
- I need to take a GUI example to connect with the audience. Past sessions
(the stack example) were quickly stereotyped as "toy examples". They like to
think that they're solving pretty complex problems (while I try to convince
them that the approach is the same) although countless other teams have
attempted similar things before

@Nicolas and Charlie
- Thanks for pointing out the typos. Haven't yet reached the proofreading
stage.. will weed out all of them a day before the presentation.

@Olof and Charlie
- this is the 3rd year I've been trying to get acceptance and I still have a
low score on that. Keep at it... Change is hard :)
 - The current audience has already shipped a product as an "agile" team.
Although I strongly suspect that TDD was done more as a process compliance
thing - they had typical issues of fragile tests / spotty test coverage /
bug churn / tech debt et. all. I think they're ready :) (although there are
about 10% that are absolute noobs. Maybe I could talk to them personally
post/pre session) They know the steps but haven't experienced the true
euphoria of TDD. Also they do not have the option now of not doing TDD -
it's a management mandate. However I see some after-effects of not enough
buy-in..

Thank you all for your time...
Just responding to your emails has given me 5-6 more avenues to pursue. Back
to the drawing board.. will post back with updates..
-- Gishu


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

[Donaldson, John (GEO)]

Charlie,

Yes, I accept pretty well all your additions and reservations.
My "2 minutes per slide" was really only a way to think about the length and complexity of Gishu's presentation.

There's definitely a trend for people to just without many slides at all. Martin Fowler is notable exponent.
But this means you have no real take-away except what sticks first time in your head.
So, in general I think slides are good if they are an addition to the session and not the main deliverable.

Gishu's presentation really marks out the territory well.
But if I think about how I would talk over some of the slides with lists (the principals and others) I think I would be wanting to show something: here's an example of how not to do this - here's an example of a simple refactoring to solve this - etc. The lists would be very difficult to do well by just standing there and talking.

The slide with the Brian Marick graphic is an example of a well-balanced slide in my opinion.

It may be that Gishu's workshop jumps off to code and demos and hands-on all the time - but we don't see that from the slides.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Charlie Poole
Sent: 01 October 2009 20:50
To: testdrivendevelopment@...
Subject: RE: [TDD] RFC: Need volunteers to review content for a TDD workshop

Hi John,

> Wow - first of all - good job - you hit all the main topics
> as far as I can see.

Agreed.

> But...
> I usually work on a rule of thumb of 2 minutes per slide, and
> your slides are going to take *much* longer than that.

In the usual "bullet point" style, I use the same guideline. But
since I read "Beyond Bullet Points" I tend to try to talk more
about each slide - and not have bullet points.

I've attended a day-long class by Ward Cunningham, which had
about 20 slides and it was - as you may imagine - quite good.

So, I think the slide count is up to the presenter.

However. I a slide is going to stay up a long time, while
the presenter speaks or exercises go on, I would tend to put
less info on one slide - perhaps a single point and accompanying
graphics.

> I`d expand several of the slides (mocks+DI, patterns,
> principals, etc) into many slides.

Yes - many of the slides could be split.

> The problem with that is that then you realize that 6 hours
> (including hands-on) is not going to fit.
>
> (And I don't think you mentioned FIT by the way, or
> refactoring tools or IDEs that help).

I'd include refactoring in a TDD presentatin but not FIT.
But of course there are different ways to slice it.
 
> So, I'd be left with reduce the content (but provide
> pointers), or stretch out to 2 days.

It's tough. My shortest hands-on TDD class is 2 days and
doesn't cover GUI. But it's possible to do highlights if
you carefully select the material. That's what I've done,
for example, when presenting at some conferences.

Charlie
 

[Adam Sroka-3]

Hi Gishu:

I like it. I have been developing a similar presentation for my new
employer. While what I came up with is significantly different I
admire what you have done and think it is excellent.

Two points:

1) I agree with what others have said, too many concepts on one slide
and you risk that people won't get even one of them. This is
particularly a concern for the SOLID stuff. I would suggest that you
incorporate the principles into live examples only one (or perhaps
two) at a time. That is what has worked for me.

2) This is more of a detail oriented thing. On "TDD In One Slide" it
is not clear to me how the diagram relates to the text. If I were in
your presentation I would spend the whole time trying to figure that
out and not hear a word you said ;-) Perhaps something like
http://en.wikipedia.org/wiki/File:Test-driven_development.PNG which is
public domain, would be a better choice for that slide.

On Thu, Oct 1, 2009 at 3:54 AM, Gishu Pillai <gishu.pillai@...> wrote:

>
>
>
> The slides for my talk is shared here
> http://docs.google.com/present/view?id=dcx49m86_22f2n8txcm
>
> My motivation behind this was : "If you had just 6-8 hrs to sell and give a
> rolling start on TDD to an audience (mixed expertise level)..."
> I've collated whatever I could think of and recollect from all the various
> books that I've read till now.
>
> There also be 2 coding exercises in between where everyone gets some
> hands-on time with TDD.
>
> I'd like some eyeballs to spot
> - mistakes
> - better ways to rephrase / shorten something
> - omissions
> - common questions / problems
>
> I couldn't collate a FAQ list (ran out of time). If someone would like to
> pitch in, I'd be happy to share access to the google doc. Just mail me your
> google id (my email address is in the last slide)
>
> Thanks
> Gishu
>
> [Non-text portions of this message have been removed]
>
>

[Olof Bjarnason]

2009/10/2 Gishu Pillai <gishu.pillai@...>

>
>
>
> @Carlo
> - Agreed, will rephrase to indicate refactoring not always = remove
> duplication... although its a 80% case
> - Koskela's book - Haven't read it yet.. Will make a note of that. The first
> batch of attendees have a .net desktop app background.. but I have a Java
> group attending in the future. I wanted that slide to be the absolute
> minimal set of must-read books ; past history indicates reading doesn't come
> easy to a majority of programmers :)
>
> @John, Carlo and Charlie
> - A clear sign that compressing SOLID is a near-miss. Thanks for pointing
> that out. My original take was to switch to a whiteboard, draw and talk with
> the audience... (not in 2 min by a long shot); However I agree that this
> needs more time and emphasis ; I guess just my mental block of someone
> starting with a presentation that says 1/78 at the bottom right. Will get to
> work on splitting atleast the SOLID priniciples out.
> - I have a 20% confidence level of getting all this done in 1 day. I guess
> will have to extend this to 2 days to avoid the audience tuning off with
> info overload ; + they'll take their time to make and recover from mistakes
> in the coding exercises, ask questions, et. all. I'm getting them to try
> pairing as well for this so .. point noted. Have to do the right thing and
> make it a 2-day workshop; Better for everyone concerned.
> - I need to take a GUI example to connect with the audience. Past sessions
> (the stack example) were quickly stereotyped as "toy examples". They like to
> think that they're solving pretty complex problems (while I try to convince
> them that the approach is the same) although countless other teams have
> attempted similar things before
>
> @Nicolas and Charlie
> - Thanks for pointing out the typos. Haven't yet reached the proofreading
> stage.. will weed out all of them a day before the presentation.
>
> @Olof and Charlie
> - this is the 3rd year I've been trying to get acceptance and I still have a
> low score on that. Keep at it... Change is hard :)
> - The current audience has already shipped a product as an "agile" team.
> Although I strongly suspect that TDD was done more as a process compliance
> thing - they had typical issues of fragile tests / spotty test coverage /
> bug churn / tech debt et. all. I think they're ready :) (although there are
> about 10% that are absolute noobs. Maybe I could talk to them personally
> post/pre session) They know the steps but haven't experienced the true
> euphoria of TDD. Also they do not have the option now of not doing TDD -
> it's a management mandate. However I see some after-effects of not enough
> buy-in..

Gishu; maybe you could present your team to the TDD problems site?

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

For example, you could have one "home work" exercise per week, or even
better reserve 2 hrs per week to practice TDD on those toy problems.

Also, if you want to add more problems, your welcome to the site
admins (I'm one of them) to get write access.
(that goes to anyone on this list who want to contribute!)

>
> Thank you all for your time...
> Just responding to your emails has given me 5-6 more avenues to pursue. Back
> to the drawing board.. will post back with updates..
> -- Gishu
>
> [Non-text portions of this message have been removed]
>
>


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

[Mark Levison-2]

Gishu - somehow I missed the original email and offline right now so I can't
look it up. I do however have some general advice/thoughts.
(My background and why I'm qualified to talk about this: Last year I became
frustrated with the quality of the teaching/presentations I was seeing - the
result a neuroscience based session at Agile2009 that addressed some of the
common problems: Learning: Best Approaches for your Brain).

- Start by discovering what your audience already knows - ask them a few
questions at the beginning of every section, you will discover all sorts of
things that they already know some good/some bad - you have to work with
this information
- Lead with the concrete - too often we start with an abstract idea and then
show concrete examples - human brains are designed to work in the other
direction.
- Make it interactive - have lots of interactive breaks, whether coding or
discussion - among other things it allows people time to integrate (i.e.
really learn the material).
- Offer lots of visuals - IStockPhoto or some of the free sites are your
friends.
- Tell stories where possible - this is what people will remember - I like
to lead with a story illustrating the pain I used to suffer (i.e. life
before TDD - so the audience can relate, my journey - so people know it took
a while and they're not stupid, my success so that they know will succeed
eventually).

Good Luck
Mark Levison

On Fri, Oct 2, 2009 at 2:02 AM, Gishu Pillai <gishu.pillai@...> wrote:

>
>
> @Carlo
> - Agreed, will rephrase to indicate refactoring not always = remove
> duplication... although its a 80% case
> - Koskela's book - Haven't read it yet.. Will make a note of that. The
> first
> batch of attendees have a .net desktop app background.. but I have a Java
> group attending in the future. I wanted that slide to be the absolute
> minimal set of must-read books ; past history indicates reading doesn't
> come
> easy to a majority of programmers :)
>
> @John, Carlo and Charlie
> - A clear sign that compressing SOLID is a near-miss. Thanks for pointing
> that out. My original take was to switch to a whiteboard, draw and talk
> with
> the audience... (not in 2 min by a long shot); However I agree that this
> needs more time and emphasis ; I guess just my mental block of someone
> starting with a presentation that says 1/78 at the bottom right. Will get
> to
> work on splitting atleast the SOLID priniciples out.
> - I have a 20% confidence level of getting all this done in 1 day. I guess
> will have to extend this to 2 days to avoid the audience tuning off with
> info overload ; + they'll take their time to make and recover from mistakes
> in the coding exercises, ask questions, et. all. I'm getting them to try
> pairing as well for this so .. point noted. Have to do the right thing and
> make it a 2-day workshop; Better for everyone concerned.
> - I need to take a GUI example to connect with the audience. Past sessions
> (the stack example) were quickly stereotyped as "toy examples". They like
> to
> think that they're solving pretty complex problems (while I try to convince
> them that the approach is the same) although countless other teams have
> attempted similar things before
>
> @Nicolas and Charlie
> - Thanks for pointing out the typos. Haven't yet reached the proofreading
> stage.. will weed out all of them a day before the presentation.
>
> @Olof and Charlie
> - this is the 3rd year I've been trying to get acceptance and I still have
> a
> low score on that. Keep at it... Change is hard :)
> - The current audience has already shipped a product as an "agile" team.
> Although I strongly suspect that TDD was done more as a process compliance
> thing - they had typical issues of fragile tests / spotty test coverage /
> bug churn / tech debt et. all. I think they're ready :) (although there are
> about 10% that are absolute noobs. Maybe I could talk to them personally
> post/pre session) They know the steps but haven't experienced the true
> euphoria of TDD. Also they do not have the option now of not doing TDD -
> it's a management mandate. However I see some after-effects of not enough
> buy-in..
>
> Thank you all for your time...
> Just responding to your emails has given me 5-6 more avenues to pursue.
> Back
> to the drawing board.. will post back with updates..
> -- Gishu
>
>
> [Non-text portions of this message have been removed]
>
>  
>

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

[Mark Levison-2]

I've not had a chance to read Gishu's presentation - but a quick reply to
John. The minimalist approach to slide decks is to counter the problem of
people reading the slides before the presenter did. As a rule if the
presenter could send the slides and have the audience read them then there
is no need for a presenter. John highlights the concern that without enough
meat in the slides there is no take away, but the slides shouldn't be trying
to solve that problem. If a take away will be useful then write a paper, in
Gishu's case I would give away copies of a good TDD book as the take away.
My key point here: the slides are there to support the presentation write
them to do that. Nothing else.
Cheers
Mark

On Fri, Oct 2, 2009 at 2:11 AM, Donaldson, John (GEO) <
john.m.donaldson@...> wrote:

>
>
> Charlie,
>
> Yes, I accept pretty well all your additions and reservations.
> My "2 minutes per slide" was really only a way to think about the length
> and complexity of Gishu's presentation.
>
> There's definitely a trend for people to just without many slides at all.
> Martin Fowler is notable exponent.
> But this means you have no real take-away except what sticks first time in
> your head.
> So, in general I think slides are good if they are an addition to the
> session and not the main deliverable.
>
> Gishu's presentation really marks out the territory well.
> But if I think about how I would talk over some of the slides with lists
> (the principals and others) I think I would be wanting to show something:
> here's an example of how not to do this - here's an example of a simple
> refactoring to solve this - etc. The lists would be very difficult to do
> well by just standing there and talking.
>
> The slide with the Brian Marick graphic is an example of a well-balanced
> slide in my opinion.
>
> It may be that Gishu's workshop jumps off to code and demos and hands-on
> all the time - but we don't see that from the slides.
>
> John D.
>
>
> -----Original Message-----
> From: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>[mailto:
> testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>]
> On Behalf Of Charlie Poole
> Sent: 01 October 2009 20:50
> To: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> Subject: RE: [TDD] RFC: Need volunteers to review content for a TDD
> workshop
>
> Hi John,
>
> > Wow - first of all - good job - you hit all the main topics
> > as far as I can see.
>
> Agreed.
>
> > But...
> > I usually work on a rule of thumb of 2 minutes per slide, and
> > your slides are going to take *much* longer than that.
>
> In the usual "bullet point" style, I use the same guideline. But
> since I read "Beyond Bullet Points" I tend to try to talk more
> about each slide - and not have bullet points.
>
> I've attended a day-long class by Ward Cunningham, which had
> about 20 slides and it was - as you may imagine - quite good.
>
> So, I think the slide count is up to the presenter.
>
> However. I a slide is going to stay up a long time, while
> the presenter speaks or exercises go on, I would tend to put
> less info on one slide - perhaps a single point and accompanying
> graphics.
>
> > I`d expand several of the slides (mocks+DI, patterns,
> > principals, etc) into many slides.
>
> Yes - many of the slides could be split.
>
> > The problem with that is that then you realize that 6 hours
> > (including hands-on) is not going to fit.
> >
> > (And I don't think you mentioned FIT by the way, or
> > refactoring tools or IDEs that help).
>
> I'd include refactoring in a TDD presentatin but not FIT.
> But of course there are different ways to slice it.
>
> > So, I'd be left with reduce the content (but provide
> > pointers), or stretch out to 2 days.
>
> It's tough. My shortest hands-on TDD class is 2 days and
> doesn't cover GUI. But it's possible to do highlights if
> you carefully select the material. That's what I've done,
> for example, when presenting at some conferences.
>
> Charlie
>
>  
>

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

[Mark Levison-2]

Gishu - somehow I missed the original email and offline right now so I can't
look it up. I do however have some general advice/thoughts.

(My background and why I'm qualified to talk about this: Last year I became
frustrated with the quality of the teaching/presentations I was seeing - the
result a neuroscience based session at Agile2009 that addressed some of the
common problems: Learning: Best Approaches for your Brain).

- Start by discovering what your audience already knows - ask them a few
questions at the beginning of every section, you will discover all sorts of
things that they already know some good/some bad - you have to work with
this information
- Lead with the concrete - too often we start with an abstract idea and then
show concrete examples - human brains are designed to work in the other
direction.
- Make it interactive - have lots of interactive breaks, whether coding or
discussion - among other things it allows people time to integrate (i.e.
really learn the material).
- Offer lots of visuals - IStockPhoto or some of the free sites are your
friends.
- Tell stories where possible - this is what people will remember - I like
to lead with a story illustrating the pain I used to suffer (i.e. life
before TDD - so the audience can relate, my journey - so people know it took
a while and they're not stupid, my success so that they know will succeed
eventually).

Good Luck
Mark Levison

On Fri, Oct 2, 2009 at 2:02 AM, Gishu Pillai <gishu.pillai@...> wrote:

>
>
> @Carlo
> - Agreed, will rephrase to indicate refactoring not always = remove
> duplication... although its a 80% case
> - Koskela's book - Haven't read it yet.. Will make a note of that. The
> first
> batch of attendees have a .net desktop app background.. but I have a Java
> group attending in the future. I wanted that slide to be the absolute
> minimal set of must-read books ; past history indicates reading doesn't
> come
> easy to a majority of programmers :)
>
> @John, Carlo and Charlie
> - A clear sign that compressing SOLID is a near-miss. Thanks for pointing
> that out. My original take was to switch to a whiteboard, draw and talk
> with
> the audience... (not in 2 min by a long shot); However I agree that this
> needs more time and emphasis ; I guess just my mental block of someone
> starting with a presentation that says 1/78 at the bottom right. Will get
> to
> work on splitting atleast the SOLID priniciples out.
> - I have a 20% confidence level of getting all this done in 1 day. I guess
> will have to extend this to 2 days to avoid the audience tuning off with
> info overload ; + they'll take their time to make and recover from mistakes
> in the coding exercises, ask questions, et. all. I'm getting them to try
> pairing as well for this so .. point noted. Have to do the right thing and
> make it a 2-day workshop; Better for everyone concerned.
> - I need to take a GUI example to connect with the audience. Past sessions
> (the stack example) were quickly stereotyped as "toy examples". They like
> to
> think that they're solving pretty complex problems (while I try to convince
> them that the approach is the same) although countless other teams have
> attempted similar things before
>
> @Nicolas and Charlie
> - Thanks for pointing out the typos. Haven't yet reached the proofreading
> stage.. will weed out all of them a day before the presentation.
>
> @Olof and Charlie
> - this is the 3rd year I've been trying to get acceptance and I still have
> a
> low score on that. Keep at it... Change is hard :)
> - The current audience has already shipped a product as an "agile" team.
> Although I strongly suspect that TDD was done more as a process compliance
> thing - they had typical issues of fragile tests / spotty test coverage /
> bug churn / tech debt et. all. I think they're ready :) (although there are
> about 10% that are absolute noobs. Maybe I could talk to them personally
> post/pre session) They know the steps but haven't experienced the true
> euphoria of TDD. Also they do not have the option now of not doing TDD -
> it's a management mandate. However I see some after-effects of not enough
> buy-in..
>
> Thank you all for your time...
> Just responding to your emails has given me 5-6 more avenues to pursue.
> Back
> to the drawing board.. will post back with updates..
> -- Gishu
>
>
> [Non-text portions of this message have been removed]
>
>  
>

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

[Mark Levison-2]

Gishu - somehow I missed the original email and offline right now so I can't
look it up. I do however have some general advice/thoughts.

(My background and why I'm qualified to talk about this: Last year I became
frustrated with the quality of the teaching/presentations I was seeing - the
result a neuroscience based session at Agile2009 that addressed some of the
common problems: Learning: Best Approaches for your Brain).

- Start by discovering what your audience already knows - ask them a few
questions at the beginning of every section, you will discover all sorts of
things that they already know some good/some bad - you have to work with
this information
- Lead with the concrete - too often we start with an abstract idea and then
show concrete examples - human brains are designed to work in the other
direction.
- Make it interactive - have lots of interactive breaks, whether coding or
discussion - among other things it allows people time to integrate (i.e.
really learn the material).
- Offer lots of visuals - IStockPhoto or some of the free sites are your
friends.
- Tell stories where possible - this is what people will remember - I like
to lead with a story illustrating the pain I used to suffer (i.e. life
before TDD - so the audience can relate, my journey - so people know it took
a while and they're not stupid, my success so that they know will succeed
eventually).

Good Luck
Mark Levison

On Fri, Oct 2, 2009 at 2:02 AM, Gishu Pillai <gishu.pillai@...> wrote:

>
>
> @Carlo
> - Agreed, will rephrase to indicate refactoring not always = remove
> duplication... although its a 80% case
> - Koskela's book - Haven't read it yet.. Will make a note of that. The
> first
> batch of attendees have a .net desktop app background.. but I have a Java
> group attending in the future. I wanted that slide to be the absolute
> minimal set of must-read books ; past history indicates reading doesn't
> come
> easy to a majority of programmers :)
>
> @John, Carlo and Charlie
> - A clear sign that compressing SOLID is a near-miss. Thanks for pointing
> that out. My original take was to switch to a whiteboard, draw and talk
> with
> the audience... (not in 2 min by a long shot); However I agree that this
> needs more time and emphasis ; I guess just my mental block of someone
> starting with a presentation that says 1/78 at the bottom right. Will get
> to
> work on splitting atleast the SOLID priniciples out.
> - I have a 20% confidence level of getting all this done in 1 day. I guess
> will have to extend this to 2 days to avoid the audience tuning off with
> info overload ; + they'll take their time to make and recover from mistakes
> in the coding exercises, ask questions, et. all. I'm getting them to try
> pairing as well for this so .. point noted. Have to do the right thing and
> make it a 2-day workshop; Better for everyone concerned.
> - I need to take a GUI example to connect with the audience. Past sessions
> (the stack example) were quickly stereotyped as "toy examples". They like
> to
> think that they're solving pretty complex problems (while I try to convince
> them that the approach is the same) although countless other teams have
> attempted similar things before
>
> @Nicolas and Charlie
> - Thanks for pointing out the typos. Haven't yet reached the proofreading
> stage.. will weed out all of them a day before the presentation.
>
> @Olof and Charlie
> - this is the 3rd year I've been trying to get acceptance and I still have
> a
> low score on that. Keep at it... Change is hard :)
> - The current audience has already shipped a product as an "agile" team.
> Although I strongly suspect that TDD was done more as a process compliance
> thing - they had typical issues of fragile tests / spotty test coverage /
> bug churn / tech debt et. all. I think they're ready :) (although there are
> about 10% that are absolute noobs. Maybe I could talk to them personally
> post/pre session) They know the steps but haven't experienced the true
> euphoria of TDD. Also they do not have the option now of not doing TDD -
> it's a management mandate. However I see some after-effects of not enough
> buy-in..
>
> Thank you all for your time...
> Just responding to your emails has given me 5-6 more avenues to pursue.
> Back
> to the drawing board.. will post back with updates..
> -- Gishu
>
>
> [Non-text portions of this message have been removed]
>
>  
>

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

[Charlie Poole-4]

Hi Mark,

The best way I've found to counter this problem is to make
slides that *illustrate* the points I'm making but which
don't actually make the points by themselves.

This initially sounds "lazy" to some folks, but it's
actually a lot of work, especially around finding the
appropriate graphics. Added to that is the fact that
you still need some sort of handout that lists the
points you cover plus any added reference material.

Charlie

> -----Original Message-----
> From: testdrivendevelopment@...
> [mailto:testdrivendevelopment@...] On Behalf Of
> Mark Levison
> Sent: Friday, October 02, 2009 7:37 AM
> To: testdrivendevelopment@...
> Subject: Re: [TDD] RFC: Need volunteers to review content for
> a TDD workshop
>
> I've not had a chance to read Gishu's presentation - but a
> quick reply to John. The minimalist approach to slide decks
> is to counter the problem of people reading the slides before
> the presenter did. As a rule if the presenter could send the
> slides and have the audience read them then there is no need
> for a presenter. John highlights the concern that without
> enough meat in the slides there is no take away, but the
> slides shouldn't be trying to solve that problem. If a take
> away will be useful then write a paper, in Gishu's case I
> would give away copies of a good TDD book as the take away.
> My key point here: the slides are there to support the
> presentation write them to do that. Nothing else.
> Cheers
> Mark
>
> On Fri, Oct 2, 2009 at 2:11 AM, Donaldson, John (GEO) <
> john.m.donaldson@...> wrote:
>
> >
> >
> > Charlie,
> >
> > Yes, I accept pretty well all your additions and reservations.
> > My "2 minutes per slide" was really only a way to think about the
> > length and complexity of Gishu's presentation.
> >
> > There's definitely a trend for people to just without many
> slides at all.
> > Martin Fowler is notable exponent.
> > But this means you have no real take-away except what sticks first
> > time in your head.
> > So, in general I think slides are good if they are an
> addition to the
> > session and not the main deliverable.
> >
> > Gishu's presentation really marks out the territory well.
> > But if I think about how I would talk over some of the slides with
> > lists (the principals and others) I think I would be
> wanting to show something:
> > here's an example of how not to do this - here's an example of a
> > simple refactoring to solve this - etc. The lists would be very
> > difficult to do well by just standing there and talking.
> >
> > The slide with the Brian Marick graphic is an example of a
> > well-balanced slide in my opinion.
> >
> > It may be that Gishu's workshop jumps off to code and demos and
> > hands-on all the time - but we don't see that from the slides.
> >
> > John D.
> >
> >
> > -----Original Message-----
> > From:
> testdrivendevelopment@...<testdrivendevelopment%40
> yahoogroups.com>[mailto:
> >
> testdrivendevelopment@...<testdrivendevelopment%40yahoogro
> > ups.com>]
> > On Behalf Of Charlie Poole
> > Sent: 01 October 2009 20:50
> > To:
> >
> testdrivendevelopment@...<testdrivendevelopment%40yahoogro
> > ups.com>
> > Subject: RE: [TDD] RFC: Need volunteers to review content for a TDD
> > workshop
> >
> > Hi John,
> >
> > > Wow - first of all - good job - you hit all the main
> topics as far
> > > as I can see.
> >
> > Agreed.
> >
> > > But...
> > > I usually work on a rule of thumb of 2 minutes per slide,
> and your
> > > slides are going to take *much* longer than that.
> >
> > In the usual "bullet point" style, I use the same
> guideline. But since
> > I read "Beyond Bullet Points" I tend to try to talk more about each
> > slide - and not have bullet points.
> >
> > I've attended a day-long class by Ward Cunningham, which
> had about 20
> > slides and it was - as you may imagine - quite good.
> >
> > So, I think the slide count is up to the presenter.
> >
> > However. I a slide is going to stay up a long time, while the
> > presenter speaks or exercises go on, I would tend to put
> less info on
> > one slide - perhaps a single point and accompanying graphics.
> >
> > > I`d expand several of the slides (mocks+DI, patterns, principals,
> > > etc) into many slides.
> >
> > Yes - many of the slides could be split.
> >
> > > The problem with that is that then you realize that 6 hours
> > > (including hands-on) is not going to fit.
> > >
> > > (And I don't think you mentioned FIT by the way, or refactoring
> > > tools or IDEs that help).
> >
> > I'd include refactoring in a TDD presentatin but not FIT.
> > But of course there are different ways to slice it.
> >
> > > So, I'd be left with reduce the content (but provide
> pointers), or
> > > stretch out to 2 days.
> >
> > It's tough. My shortest hands-on TDD class is 2 days and
> doesn't cover
> > GUI. But it's possible to do highlights if you carefully select the
> > material. That's what I've done, for example, when
> presenting at some
> > conferences.
> >
> > Charlie
> >
> >  
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Mark Levison-2]

Charlie - by and large we're on the same page. The key is to be aware of the
problem and consider whether you need to create a separate
handout/article/book for the take away.

Cheers
Mark

On Fri, Oct 2, 2009 at 1:11 PM, Charlie Poole <cpoole@...>wrote:

>
>
> Hi Mark,
>
> The best way I've found to counter this problem is to make
> slides that *illustrate* the points I'm making but which
> don't actually make the points by themselves.
>
> This initially sounds "lazy" to some folks, but it's
> actually a lot of work, especially around finding the
> appropriate graphics. Added to that is the fact that
> you still need some sort of handout that lists the
> points you cover plus any added reference material.
>
> Charlie
>
>
> > -----Original Message-----
> > From: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> > [mailto:testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>]
> On Behalf Of
> > Mark Levison
> > Sent: Friday, October 02, 2009 7:37 AM
> > To: testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> > Subject: Re: [TDD] RFC: Need volunteers to review content for
> > a TDD workshop
> >
> > I've not had a chance to read Gishu's presentation - but a
> > quick reply to John. The minimalist approach to slide decks
> > is to counter the problem of people reading the slides before
> > the presenter did. As a rule if the presenter could send the
> > slides and have the audience read them then there is no need
> > for a presenter. John highlights the concern that without
> > enough meat in the slides there is no take away, but the
> > slides shouldn't be trying to solve that problem. If a take
> > away will be useful then write a paper, in Gishu's case I
> > would give away copies of a good TDD book as the take away.
> > My key point here: the slides are there to support the
> > presentation write them to do that. Nothing else.
> > Cheers
> > Mark
> >
> > On Fri, Oct 2, 2009 at 2:11 AM, Donaldson, John (GEO) <
> > john.m.donaldson@... <john.m.donaldson%40hp.com>> wrote:
> >
> > >
> > >
> > > Charlie,
> > >
> > > Yes, I accept pretty well all your additions and reservations.
> > > My "2 minutes per slide" was really only a way to think about the
> > > length and complexity of Gishu's presentation.
> > >
> > > There's definitely a trend for people to just without many
> > slides at all.
> > > Martin Fowler is notable exponent.
> > > But this means you have no real take-away except what sticks first
> > > time in your head.
> > > So, in general I think slides are good if they are an
> > addition to the
> > > session and not the main deliverable.
> > >
> > > Gishu's presentation really marks out the territory well.
> > > But if I think about how I would talk over some of the slides with
> > > lists (the principals and others) I think I would be
> > wanting to show something:
> > > here's an example of how not to do this - here's an example of a
> > > simple refactoring to solve this - etc. The lists would be very
> > > difficult to do well by just standing there and talking.
> > >
> > > The slide with the Brian Marick graphic is an example of a
> > > well-balanced slide in my opinion.
> > >
> > > It may be that Gishu's workshop jumps off to code and demos and
> > > hands-on all the time - but we don't see that from the slides.
> > >
> > > John D.
> > >
> > >
> > > -----Original Message-----
> > > From:
> > testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> <testdrivendevelopment%40
> > yahoogroups.com>[mailto:
> > >
> > testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> <testdrivendevelopment%40yahoogro
> > > ups.com>]
> > > On Behalf Of Charlie Poole
> > > Sent: 01 October 2009 20:50
> > > To:
> > >
> > testdrivendevelopment@...<testdrivendevelopment%40yahoogroups.com>
> <testdrivendevelopment%40yahoogro
>
> > > ups.com>
> > > Subject: RE: [TDD] RFC: Need volunteers to review content for a TDD
> > > workshop
> > >
> > > Hi John,
> > >
> > > > Wow - first of all - good job - you hit all the main
> > topics as far
> > > > as I can see.
> > >
> > > Agreed.
> > >
> > > > But...
> > > > I usually work on a rule of thumb of 2 minutes per slide,
> > and your
> > > > slides are going to take *much* longer than that.
> > >
> > > In the usual "bullet point" style, I use the same
> > guideline. But since
> > > I read "Beyond Bullet Points" I tend to try to talk more about each
> > > slide - and not have bullet points.
> > >
> > > I've attended a day-long class by Ward Cunningham, which
> > had about 20
> > > slides and it was - as you may imagine - quite good.
> > >
> > > So, I think the slide count is up to the presenter.
> > >
> > > However. I a slide is going to stay up a long time, while the
> > > presenter speaks or exercises go on, I would tend to put
> > less info on
> > > one slide - perhaps a single point and accompanying graphics.
> > >
> > > > I`d expand several of the slides (mocks+DI, patterns, principals,
> > > > etc) into many slides.
> > >
> > > Yes - many of the slides could be split.
> > >
> > > > The problem with that is that then you realize that 6 hours
> > > > (including hands-on) is not going to fit.
> > > >
> > > > (And I don't think you mentioned FIT by the way, or refactoring
> > > > tools or IDEs that help).
> > >
> > > I'd include refactoring in a TDD presentatin but not FIT.
> > > But of course there are different ways to slice it.
> > >
> > > > So, I'd be left with reduce the content (but provide
> > pointers), or
> > > > stretch out to 2 days.
> > >
> > > It's tough. My shortest hands-on TDD class is 2 days and
> > doesn't cover
> > > GUI. But it's possible to do highlights if you carefully select the
> > > material. That's what I've done, for example, when
> > presenting at some
> > > conferences.
> > >
> > > Charlie
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>  
>

   *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]

[Charlie Poole-4]

Hi John,

> Yes, I accept pretty well all your additions and reservations.
> My "2 minutes per slide" was really only a way to think about
> the length and complexity of Gishu's presentation.

Yes. And in a pinch, when I fall back to the "standard"
bullet points approach, I use the same estimate myself.
 
> There's definitely a trend for people to just without many
> slides at all. Martin Fowler is notable exponent.

I've done this for an hour or two but I would probably not
do it for a day. BTW, the first time I did a slideless
presentation was due to my having misplaced my US-UK power
adapter. I ended up talking while drawing a mindmap on
a large easel pad. It went over so well I now do it on
purpose.


> But this means you have no real take-away except what sticks
> first time in your head.

Unless you create a takeaway document. That has some advantages
over slide images, since it can be created in a more suitable
form for reading.

> So, in general I think slides are good if they are an
> addition to the session and not the main deliverable.

Yes.
 
> Gishu's presentation really marks out the territory well.
> But if I think about how I would talk over some of the slides
> with lists (the principals and others) I think I would be
> wanting to show something: here's an example of how not to do
> this - here's an example of a simple refactoring to solve
> this - etc. The lists would be very difficult to do well by
> just standing there and talking.

In addition to wanting something to show, the list approach
has the problem that the audience is looking at what you
previously discussed and what you're about to discuss in
addition to what you are actually discussing. For a slide
that's up for only two minutes it's not a problem, but if
it's likely to be shown for 10 minutes or more - as in the
case of some of the design principles - I'd like the slide
to make only one point.

> The slide with the Brian Marick graphic is an example of a
> well-balanced slide in my opinion.

Yes.
 
> It may be that Gishu's workshop jumps off to code and demos
> and hands-on all the time - but we don't see that from the slides.

Sometimes I create summary slides, with a number of points
on them to shoow while exercises are taking place.

Charlie

> John D.
>
> -----Original Message-----
> From: testdrivendevelopment@...
> [mailto:testdrivendevelopment@...] On Behalf Of
> Charlie Poole
> Sent: 01 October 2009 20:50
> To: testdrivendevelopment@...
> Subject: RE: [TDD] RFC: Need volunteers to review content for
> a TDD workshop
>
> Hi John,
>
> > Wow - first of all - good job - you hit all the main topics
> as far as
> > I can see.
>
> Agreed.
>
> > But...
> > I usually work on a rule of thumb of 2 minutes per slide, and your
> > slides are going to take *much* longer than that.
>
> In the usual "bullet point" style, I use the same guideline.
> But since I read "Beyond Bullet Points" I tend to try to talk
> more about each slide - and not have bullet points.
>
> I've attended a day-long class by Ward Cunningham, which had
> about 20 slides and it was - as you may imagine - quite good.
>
> So, I think the slide count is up to the presenter.
>
> However. I a slide is going to stay up a long time, while the
> presenter speaks or exercises go on, I would tend to put less
> info on one slide - perhaps a single point and accompanying graphics.
>
> > I`d expand several of the slides (mocks+DI, patterns,
> principals, etc)
> > into many slides.
>
> Yes - many of the slides could be split.
>
> > The problem with that is that then you realize that 6 hours
> (including
> > hands-on) is not going to fit.
> >
> > (And I don't think you mentioned FIT by the way, or
> refactoring tools
> > or IDEs that help).
>
> I'd include refactoring in a TDD presentatin but not FIT.
> But of course there are different ways to slice it.
>  
> > So, I'd be left with reduce the content (but provide pointers), or
> > stretch out to 2 days.
>
> It's tough. My shortest hands-on TDD class is 2 days and
> doesn't cover GUI. But it's possible to do highlights if you
> carefully select the material. That's what I've done, for
> example, when presenting at some conferences.
>
> Charlie
>  
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Gishu P]

Hi everyone,

Put some more hours into it. Revision 2 can be found at the following link
(although the previous one should work just as well.)

http://docs.google.com/present/edit?id=0AaQfN_JAz01mZGN4NDltODZfMjJmMm44dHhjbQ&hl=en

Thanks,
Gishu


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

[Charlie Poole-4]

Hi Gishu,

I really like what you've done with the design principles!

Charlie

> -----Original Message-----
> From: testdrivendevelopment@...
> [mailto:testdrivendevelopment@...] On Behalf Of
> Gishu Pillai
> Sent: Monday, October 05, 2009 12:49 PM
> To: testdrivendevelopment@...
> Subject: Re: [TDD] RFC: Need volunteers to review content for
> a TDD workshop
>
> Hi everyone,
>
> Put some more hours into it. Revision 2 can be found at the
> following link (although the previous one should work just as well.)
>
> http://docs.google.com/present/edit?id=0AaQfN_JAz01mZGN4NDltOD
> ZfMjJmMm44dHhjbQ&hl=en
>
> Thanks,
> Gishu
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>