TDD kata feedback

[Jeff L.]

In the first day of a two-day overview of TDD (preceding some hands-on
coaching), I introduced the Roman number conversion (int -> Roman) as
a 2nd exercise, with the primary discussion points around incremental
growth using TDD and what tests to choose next. This is the about the
4th time I've used this exercise in a classroom setting and so far
it's seemed to have worked well (no negative feedback, and provoked
some good thoughts / discussions).

One of the students (I'm sure I know which student it was) left this
feedback on a card that I didn't see until the end of the day, so I
didn't have a chance to respond:
"Roman numeral exercise proved to me that TDD is not for me. I
would've done it more quickly and painlessly if I did it using a top-
down algorithm approach."

The student in question expressed concern during the exercise. As I
attempted to provide a bit of guidance, I noted that the code was a
mess somewhat commonplace for this exercise--no real attempts at
factoring the code. I had given strong "hints" up front--most
importantly 1. choose the next test carefully and 2. absolutely kill
duplication at each step (and make similar code look just like other
code in order to get rid of it). After the exercise, we also had a
good deal of discussion about what katas are and why you do them, and
also about algorithms, TDD, and insights.

So: bad choice for a second exercise (I don't think so, but who
knows)? Has anyone had similar feedback--where an exercise convinced
someone that TDD sucked? Is this a closed-minded individual (or am I
not hearing him well--I don't like to assume I'm dealing with someone
who's already made up their mind)?

I am thinking about what, if anything, to say to the class tomorrow.
Or to the individual. Many thoughts come to mind, and many thoughts
about not saying too much also come to mind.

What would you say/do? Thanks in advance for any thoughts.

Jeff

[John Goodsen]

never underestimate the ability for a programmer that views coding as a just a job to deride something they will never become good at as a result.

last week, we did 2 word-wrap code kata sessions, then the bowling game kata.  Because after the 2nd day, it seemed clear that developers weren't interested in what seemed to be a trivial piece of code and solution.... but most of these developers really *do* want to get better, so I am more inclined to think the first kata was too trivial to engage them as a first kata - I think they almost need a more complex kata for the first introduction -- to engage them into how even something as trivial as scoring a bowling game turns out to be a lot of testing and refactoring to keep it clean.

I also wonder if we should introduce deeper concepts before katas - like "software as a craft" -- concepts that make people realize this is a craft and if they want to be good at it, it takes practice and mentoring - not a college degree in C.S. and a mediocre understanding converting XML files to stack traces with Java programs.... and that this profession requires attention after our 8-5pm workdays.

jg

[Dale Emery]

Hi Jeff,

> So: bad choice for a second exercise (I don't think so, but who knows)? Has anyone had similar feedback--where an exercise convinced someone that TDD sucked? Is this a closed-minded individual (or am I not hearing him well--I don't like to assume I'm dealing with someone who's already made up their mind)?

You can't tell much from one experience. All you know is that this exercise didn't fit for this person at this time. At another time... who knows?

So make a note, and notice over time whether or not it becomes a pattern.

Dale

--
Dale Emery
Consultant to software teams and leaders
http://dhemery.com

[Jeff Langr]

Hi John,

Thanks for the feedback! 

> never underestimate the ability for a programmer that views coding as a just a 

> job to deride something they will never become good at as a result.

Now now, that's the cynical route I was hoping to keep myself from. :-) My cynical thought is that this gentleman thinks he's good at programming and hasn't yet found an appropriate amount of humility.

The first exercise they did (this was the 2nd) was a multi-map--something they might actually use in real code, but something that's simple enough (and yet not too simple--it's still possible to botch) to allow them to focus more on the concepts & techniques. After trying a number of different first introductions, I've found this to be most effective.

Thanks for the additional ideas around introducing craft (I do emphasize practice and additional investment in time).

Jeff
Langr Software Solutions
http://langrsoft.com
http://agileinaflash.com

[George Dinwiddie]

Jeff,

The pattern I've noticed over time is that a lot of students dismiss
tiny programs, particularly algorithmic ones, as something to "just type
in" rather than develop.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[John Goodsen]

Yeah, what George said :)   I'd say, choose our "training" katas wisely - weird how the older we get, the more we like simple problems to practice with... and yeah, I'm wearing reading glasses now.

coincidence?  perhaps not.

[RonJeffries]

Hi Jeff,

On Feb 21, 2012, at 10:51 PM, Jeff L. wrote:

I am thinking about what, if anything, to say to the class tomorrow.
Or to the individual. Many thoughts come to mind, and many thoughts
about not saying too much also come to mind.

What would you say/do? Thanks in advance for any thoughts.

I try to make these points fairly explicit:

• This is the way I program. I've programmed in every way known to man, and I like this way best.
• In real code, when for any reason, I don't TDD, I find that I have more tension, more defects, and longer debugging sessions.
• Speaking of debugging, I don't even know how to work the debugger in most of the IDEs and languages I use, because I have no occasion to. All defects are shallow when the code worked a couple of minutes ago.
• Even on these easy problems, TDD is not easy to do. You don't have to do TDD, but my advice is that you should practice it until you're good enough that I'd publicly recognize you as good at it, and only then decide where it fits in to your life.

Ron Jeffries

www.XProgramming.com

 Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[J. B. Rainsberger]

On Wed, Feb 22, 2012 at 05:51, Jeff L. <jjl...@gmail.com> wrote:

> I am thinking about what, if anything, to say to the class tomorrow.
> Or to the individual. Many thoughts come to mind, and many thoughts
> about not saying too much also come to mind.
>
> What would you say/do? Thanks in advance for any thoughts.

When this happens to me, I tell people the story of why I started
doing test-first programming. I emphasise that I first decided to try
it out of curiousity and interest, then jumped in with both feet when
I had to rebuild something I'd been working on for 3 months, from
scratch, in 3 weeks. I did it 9 days. Since then, I've seen and felt
the benefits of first test-first programming, then TDD.

Two key points to the story: (1) at first I found the idea of TFP
intriguing, and not everyone does; (2) I used TFP in anger and it
saved my ass, and not everyone experiences that.

"Who knows how I would have turned out differently if neither (1) nor
(2) happened? I might never have taken TDD seriously. That's OK. It's
OK if you don't, either.

"My goal in 3 days (or however long) is to expose you to what helps
me, give you the chance to try it and ask tough questions, give you
no-bullshit answers, then let you decide what you want to do next. I'm
not here to convert anyone, and I don't mind if you decide after 3
days that I'm full of shit and you're not going to do TDD. When you
want to do TDD, I'll help."

I noticed that when I stopped worrying about whether my students
actually did what I showed them after I left, then I felt less
tension, less resistance, and might even have got through to more
people.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Author, JUnit Recipes
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com
Find out what others have to say about me at http://nta.gs/jbrains

[John Goodsen]

Hi Ron, I like this - I'm gonna share with students in code kata today, if you don't mind. :)

[RonJeffries]

I don't mind. Neither do the students, as far as I can tell. :)

R

On Feb 22, 2012, at 9:12 AM, John Goodsen wrote:

Hi Ron, I like this - I'm gonna share with students in code kata today, if you don't mind. :)

Ron Jeffries

www.XProgramming.com

I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

[Jon Kern]

LOL

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

John Goodsen said the following on 2/22/12 2:32 AM:

[Jon Kern]

jeff,

when you wrap up the kata session, do you attempt to get the group to
explain what just happened? how they feel about TDD, what sorts of
benefits they might see, etc.? In other words, this sort of group
feedback thing -- versus you espousing the virtues of TDD -- might be
the sort of thing to prod the individual to see things differently.
depending on how much they value their peers' opinions and observations.

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Jeff L. said the following on 2/21/12 10:51 PM:

[Jeff L.]

Hi John--
Right. There's a balance between trivial and non-real-world-like
vs.something that could take too long in a class environment and
somethingthat could also have the detriment of them thinking too much
about thespecific problem and not enough about the technique.
I need my reading glasses late in the day. Right now I'm proudly using
an8point font. I won't be able to read this email later without
glasses, goodthing I woke up early.
Jeff
Langr Software Solutionshttp://langrsoft.comhttp://agileinaflash.com
<http://agileinaflash.com--/> - Agile in a Flash:

[Jeff L.]

Hi George,
I've seen some evidence of this, too. Today they'll work in a "real"
code base and test drive things into that; I think that helps them
believe this could be done in their environment.
Jeff

[Jeff L.]

Hi Ron,
I like the list--thank you!

"This is the way I program. I've programmed in every way known to man,

and I like this way best."Yes. That's something I mentioned twice
yesterday.

"In real code, when for any reason, I don't TDD, I find that I have

more tension, more defects, and longer debugging sessions."I have a
couple good stories about this, I told one early yesterday. I like the
part about tension.

"Speaking of debugging, I don't even know how to work the debugger in
most of the IDEs and languages I use, because I have no occasion to.
All defects are shallow when the code worked a couple of minutes

ago."I alluded to this but didn't specifically mention it.

"Even on these easy problems, TDD is not easy to do. You don't have to
do TDD, but my advice is that you should practice it until you're good
enough that I'd publicly recognize you as good at it, and only then

decide where it fits in to your life."I think I need to hit on the
last part of this, particularly, today.
Jeff

[Jeff L.]

Hi JB--
This is a good reminder for me of your "greatest XP misses" talk--a
great summary of all the ways to try to change people that usually
don't work.

> I noticed that when I stopped worrying about whether my students> actually did what I showed them after I left, then I felt less> tension, less resistance, and might even have got through to more> people.

I do try to take this attitude, yet I suspect I probably still come
across as "I implore you" (but I always tell them that they have to
decide for themselves after giving it a fair shot).
Thanks,Jeff

On Feb 22, 4:41 am, "J. B. Rainsberger" <m...@jbrains.ca> wrote:

[Jeff L.]

Hi Jon--
Yes, though I think now that I should have expanded the discussion
about this kata a bit more. The guy in question chose not to bring up
his concern at this time. I start each day with "feelings about
yesterday," so hopefully it will come out this morning.
Long ago I used to initiate the course by asking about peoples'
concerns, then quickly realized it was getting in the way--the good
discussions can come out through the exercises. I still have a vestige
of touted benefits, but I think I should squelch this explicitness and
let it come out ... incrementally.
Thanks,
Jeff

[Erik G. H. Meade]

Messy code with bugs? Or is it so messy as to not be obvious there are no bugs?

Rationally, it sounds like a long loving talk about econcomics of clean teasted code, code smells, etc. I try to take on the tone Ron does. If I really care, I'll try to schedule some non-class time so it isn't all public and in front of the class.

"Jeff L." <jjl...@gmail.com> wrote:
> ...

[Lance Walton]

I have been struggling with something over the past few years after doing TDD or it's predecessors since about 1999.

I'm finding that because TDD pushes you towards small things, and because of some very good mentoring in the late 1990's, everything I write is tiny and looks like a toy problem. Many times, I've had those who don't understand TDD say things like "Why did you bother to write tests for all this? It's all too simple to bother.", which has some resonance with "Test Everything That Could Possibly Break", where there is errr… nothing that could possibly break, because it's all so simple (take that last bit with some humour please).

And yet, when I do write the code without TDDing it, although I maintain the smallness and the simplicity, I often find defects.

So my answer to this issue is that ALL well factored code has that "toy problem" quality to it, and indeed that is what should be aspired to. If you only aim to TDD (or test after the fact) the complex stuff, then I can pretty much guarantee that you will get a lot of complex stuff, most of which won't work. And the anecdotal evidence we have for this is overwhelming (in the financial sector in which I tend to work).

Regards,

Lance

_________________

http://www.stateofflow.com

http://www.casualmiracles.com
http://www.twitter.com/lancewalton

+44 (0)7779 026533

[RonJeffries]

Hi Lance,

On Feb 22, 2012, at 12:21 PM, Lance Walton wrote:

So my answer to this issue is that ALL well factored code has that "toy problem" quality to it, and indeed that is what should be aspired to. If you only aim to TDD (or test after the fact) the complex stuff, then I can pretty much guarantee that you will get a lot of complex stuff, most of which won't work. And the anecdotal evidence we have for this is overwhelming (in the financial sector in which I tend to work).

Yes. I am reminded of a story of a very good woman manager whose projects all came in on time, while the managers around her were screwing up right and left. When raise time came, the other managers got a bigger raise than she did. Angry, she asked why.

She was told that their projects were hard, and all hers had turned out to be easy.

Ron Jeffries

www.XProgramming.com

If another does not intend offense, it is wrong for me to seek it;

if another does indeed intend offense, it is foolish for me to permit it.

  -- Kelly Easterley

[Charlie Poole]

HI Ron,

So TDD is a technique that makes all your work look so easy that it doesn't
seem you needed to do it in the first place!

Charlie

[Jeff Langr]

That's a good insight. I remember initially working with Smalltalk and thinking, "all these tiny methods, where's all the real work getting done?"

"If you only aim to TDD (or test after the fact) the complex stuff, then I can pretty much guarantee that you will get a lot of complex stuff, most of which won't work."

- this makes for a good tweet, hope you don't mind.

Langr Software Solutions
http://langrsoft.com
http://agileinaflash.com

[Jeff Langr]

Ron said:

> I am reminded of a story of a very good woman manager whose projects all came in on time, 

> while the managers around her were screwing up right and left. When raise time came, the 

> other managers got a bigger raise than she did. Angry, she asked why.

> 

> She was told that their projects were hard, and all hers had turned out to be easy.

Fun story. Jon Stahl's team at NW was very successful, but everyone else dismissed it because it wasn't as complex as their projects.

Jeff

[Jeff Langr]

Thanks Erik. I told the guy that we could hash through things later in the week when we get to pair together.

Jeff

Langr Software Solutions
http://langrsoft.com
http://agileinaflash.com

[RonJeffries]

Hi Charlie,

On Feb 22, 2012, at 2:51 PM, Charlie Poole wrote:

So TDD is a technique that makes all your work look so easy that it doesn't
seem you needed to do it in the first place!

:) Probably not. In another context, Ward suggested to me one time that everyone pretty much gets called upon to work at the limit of their powers anyway. So TDD probably really means you just get harder and harder things to do. But I do feel I can usually keep the code simple.

Ron Jeffries

www.XProgramming.com

There's no word for accountability in Finnish. Accountability is something that is left when responsibility has been subtracted. 

--Pasi Sahlberg

[Lance Walton]

> "If you only aim to TDD (or test after the fact) the complex stuff, then I can pretty much guarantee that you will get a lot of complex stuff, most of which won't work."
> - this makes for a good tweet, hope you don't mind.

Feel free.

[D.André Dhondt]

On Tue, Feb 21, 2012 at 10:51 PM, Jeff L. <jjl...@gmail.com> wrote:

"Roman numeral exercise proved to me that TDD is not for me. I
would've done it more quickly and painlessly if I did it using a top-
down algorithm approach."

We used to do "cowboy coding contests" every couple of weeks where all coding styles were welcome--the only thing that counts is getting working code first. We found that for simple algorithms, it was easier to do without TDD; for anything non-trivial, TDD was the clear winner. Why get involved in a person's internal battles? Just give the person more experience to learn for him/her self.

Another way to shake things up is to have changing requirements--halfway through the coding exercise, break people's assumptions and see who can respond quicker. 

--
D. André Dhondt

Executive/Agile Software Coach

www.Dhondt-Teams-Gel.com

mobile: 215-805-0819
skype: d.andre.dhondt

twitter: @adhondt   http://dhondtsayitsagile.blogspot.com/

Support low-cost conferences -- http://AgileTour.org/
If you're in the area, join Agile Philly http://www.AgilePhilly.com

[J. B. Rainsberger]

On Wed, Feb 22, 2012 at 19:21, Lance Walton <lance...@mac.com> wrote:

> So my answer to this issue is that ALL well factored code has that "toy
> problem" quality to it, and indeed that is what should be aspired to.

+1

I tell people that there are no large, well-factored systems.
Well-factored systems are loosely-coupled, highly-cohesive networks of
small things. Forward UK seems to provide an example of this, at least
in legend.

[John Goodsen]

it's an interesting dynamic - we make it look easy and the business forgets that it's hard work

I'm feeling it a little in a Lean Startup that I'm a co-founder/partner in.  The other partners are high-level business and sales guys and it's a constant conversation to remind them that painless and smooth the system is a direct result of how disciplined we are in the development process - to them, it looks like we don't have a lot to work when we can create, test and enable feature experiments in the code within a few hours or a day or two at the most - when in most enterprisey places I work, it might take weeks  to do the same.

we've actually joked about release some known defects sometimes just to create an emergency and let them experience some pain to remind them of our value -- how sick is that?

jg

[J. B. Rainsberger]

On Thu, Feb 23, 2012 at 00:07, John Goodsen <john.g...@gmail.com> wrote:

> we've actually joked about release some known defects sometimes just to
> create an emergency and let them experience some pain to remind them of our
> value -- how sick is that?

Sick, but in the awesome sense of the word.

[Mark Levison]

On Wed, Feb 22, 2012 at 9:51 AM, Jon Kern <jonk...@gmail.com> wrote:

when you wrap up the kata session, do you attempt to get the group to explain what just happened? how they feel about TDD, what sorts of benefits they might see, etc.? In other words, this sort of group feedback thing -- versus you espousing the virtues of TDD -- might be the sort of thing to prod the individual to see things differently. depending on how much they value their peers' opinions and observations.

Related to this I've dropped pretty much any mention of waterfall from my Scrum training's. At the beginning (with a picture of a broken pencil the background) I say "This is not that". I.E. Scrum isn't like this other thing you already know. I ask them to set aside their preconceived notions for two days and just assume this is different. I say this might not work for them but while they're present I ask that they put their best efforts into making it work.

Cheers

Mark

[Jon Kern]

and *that* is very hard to do, Lance

it takes lots of practice and even more discipline (which i lack much of the time). and it is *really* hard to convince a newbie-to-TDD that it is worth all that silliness. i think it might require a personal epiphany, much like many personal "arts" -- be they mental or physical disciplines (like yoga or tai chi or martial arts, etc.).

sometimes i explore something new without TDD. on "good jon" days i throw away that "prototype" code and do it again using TDD. (on "bad jon" days i write tests after the fact :-o)

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Lance Walton said the following on 2/22/12 12:21 PM:

I have been struggling with something over the past few years after doing TDD or it's predecessors since about 1999.

I'm finding that because TDD pushes you towards small things, and because of some very good mentoring in the late 1990's, everything I write is tiny and looks like a toy problem. Many times, I've had those who don't understand TDD say things like "Why did you bother to write tests for all this? It's all too simple to bother.", which has some resonance with "Test Everything That Could Possibly Break", where there is errr� nothing that could possibly break, because it's all so simple (take that last bit with some humour please).

[Jon Kern]

i hope she found a better place to work, and then quit

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

RonJeffries said the following on 2/22/12 2:10 PM:

Ron Jeffries

www.XProgramming.com

� -- Kelly Easterley

[Jon Kern]

you have to constantly remind the business about the value we can bring
to building quality software... imho, this is the bane of our software
discipline.

the average PHB (or end user, or your Mom, or most any developer) has no
clue if the code is of the right level of quality and design for the
purpose at hand. assuming long-term/critical business apps, the average
manager wouldn't know if it was a pile of monolithic, tightly-coupled
crap; a phd-worthy, abstract wonder of unrecognizable-to-the-business
crap; or a well-designed, elegant solution that meets the current needs,
and is very easily adaptable to grow as the business grows thing of beauty.

who's to say... in the engineering world, you *can* over design systems.
and indeed, so it is in the software world. the average coder is likely
not going to be able to make the kinds of judgment calls that a seasoned
developer/designer/architect can make about design decisions that
dictate over- or under-design.

i tend to feel that a design that is as true to the business domain as
makes sense, coupled with a technical architecture and design that
follows sound design/coding principles, coupled with a suite of
surrounding tests; meets the vast majority of business apps. naturally,
there are apps on the fringes that need less care (throw-away prototypes
or short-lived demos), and some that need a lot more care (human-rated,
things that can kill/maim).

so keep reminding them that much like in their "real world" where smooth
operations and ease don't happen by magic, the same goes for our less
visible world. maybe you can also keep a growing chart of some
heuristics... new user signups, webapp usage stats, business features
implemented, LOCs, bugs found, bugs squashed... some giant radiators
that you can change up every so often to spur conversation about how
amazing your team is :-)

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

John Goodsen said the following on 2/22/12 5:07 PM:

[Lance Walton]

On 24 Feb 2012, at 02:29, Jon Kern wrote:

sometimes i explore something new without TDD. on "good jon" days i throw away that "prototype" code and do it again using TDD. (on "bad jon" days i write tests after the fact :-o)

The first rule of the Not Test First Club is "There is no Not Test First Club"

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Lance Walton said the following on 2/22/12 12:21 PM:

I have been struggling with something over the past few years after doing TDD or it's predecessors since about 1999.

I'm finding that because TDD pushes you towards small things, and because of some very good mentoring in the late 1990's, everything I write is tiny and looks like a toy problem. Many times, I've had those who don't understand TDD say things like "Why did you bother to write tests for all this? It's all too simple to bother.", which has some resonance with "Test Everything That Could Possibly Break", where there is errr… nothing that could possibly break, because it's all so simple (take that last bit with some humour please).

[Jon Kern]

yea, it's hard to be perfect

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Lance Walton said the following on 2/24/12 1:44 AM:

On 24 Feb 2012, at 02:29, Jon Kern wrote:

sometimes i explore something new without TDD. on "good jon" days i throw away that "prototype" code and do it again using TDD. (on "bad jon" days i write tests after the fact :-o)

The first rule of the Not Test First Club is "There is no Not Test First Club"

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Lance Walton said the following on 2/22/12 12:21 PM:

I have been struggling with something over the past few years after doing TDD or it's predecessors since about 1999.

I'm finding that because TDD pushes you towards small things, and because of some very good mentoring in the late 1990's, everything I write is tiny and looks like a toy problem. Many times, I've had those who don't understand TDD say things like "Why did you bother to write tests for all this? It's all too simple to bother.", which has some resonance with "Test Everything That Could Possibly Break", where there is errr� nothing that could possibly break, because it's all so simple (take that last bit with some humour please).

[RonJeffries]

It's hard BEING perfect, too.

R

On Feb 24, 2012, at 7:53 AM, Jon Kern wrote:

yea, it's hard to be perfect

Ron Jeffries

www.XProgramming.com

Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

[Jon Kern]

rof,l

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

RonJeffries said the following on 2/24/12 9:11 AM:

[George Dinwiddie]

Jeff,

I had the same experience at NW. From that I learned that an important
aspect of successful Agile teams in Enterprise situations is good PR.

- George

[Adrian Howard]

On Wednesday, 22 February 2012 21:29:49 UTC, D.André Dhondt wrote:

[snip]

We used to do "cowboy coding contests" every couple of weeks where all coding styles were welcome--the only thing that counts is getting working code first. We found that for simple algorithms, it was easier to do without TDD; for anything non-trivial, TDD was the clear winner. Why get involved in a person's internal battles? Just give the person more experience to learn for him/her self.

[snip]

That reminded me of an exercise I tried once. 

1) We did the bowling game kata - with people doing their preferred style (about 1/3 TDD, 2/3 other)
2) Everybody was timed - with an explicit "race to finish first with working code" goal.
3) Then everybody took their neighbours code and tried to find and fix any bugs - with a verbal shout every time a bug was found and when the  code was thought correct. 
4) Stop when everybody agreed that there were no more bugs to find

Graph up the dev time, "time to no bugs" and number of bugs on the wall. Discuss.

A bunch of interesting things game out:
* obvious trend on the graph for TDD solutions to take longer to write, but faster to get to written+"no bugs".
* obvious trend that non-TDD code took longer to get to "no bugs" (even if it had few bugs)
* general comments that the TDD code was easier to understand (even if wrong), debug and fix
* a nice conversation about the one bloke who was good/lucky enough to write a "perfect" solution first time sans-tests (his code was nice, and correct, but even with that the total time to write+review was still only slightly quicker than the TDD solutions)
* a nice conversation around a couple of places where people found bugs that weren't bugs 

Only ever did it the one time - so no idea if it generally works well - but might be worth a try.

Cheers,

Adrian

[Jon Kern]

wonderful...

so next step, introduce a very subtle bug/add new features -- something to show that once you have invested in your tests, you gain ever greater benefits (kind of like investments compounding over time).

jon

blog: http://technicaldebt.com
twitter: http://twitter.com/JonKernPA

Adrian Howard said the following on 2/24/12 1:01 PM:

[Jeff Langr]

Adrian's exercise is a great idea, something I've wanted to try for some time, but couldn't figure out how to work it in (particularly in a short class designed to teach TDD). Thanks for relaying it and the results.

I'd definitely add the follow-up Jon suggested--to throw in a new requirement wrinkle once they got the initial code working, then see how well each group accommodated it.

Thanks to all who posted & provided info/insights on my original posting. I did pair with the "algorithm guy" twice now (his actual primary role on the team--an R&D role). We started in on an example, building a shortest path algorithm very related to some of the stuff he's doing with social networks. I asked him first which direction he wanted to go: to implement code toward a known algorithm or to try and test-drive our way into a working algorithm that we were trying to devise. I also asked him which he was really doing; he said it was a bit of both.

For our exercise, we chose the latter--imagine we don't know Dijkstra's shortest path algorithm. Some of the discussion points:

- there's a good amount of "simple" test driving to do to support just the notion of a graph (edges, vertices, some simple querying).

- initial tests covered the assumption that all edges were of distance 0. We figure it should be easy to add distances once the algorithm is otherwise done.

- we got to a 4th test around shortestDistance. First: A->A is distance 0. Then A->B where they never connect is infinity. Third: A->B->C (solution: simple count of nodes). Then A->B->C->D; his solution was to use set intersection between adjoining nodes and neighbors. Very easy, very test-drivable, and on the way to something similar to Dijkstra's algorithm.

- we factored things like set intersection stuff into reusable building blocks (two lines of cluttered java code->one declarative line in this example) in order to make everything easier (and easier to incorporate use of TDD)

- He realized how refactoring to try to shape into duplication (that you then remove) is critical as you go along. This was what he'd struggled with for the Roman numeral example.

- When playing with the 4th test, we broke a couple other tests, great for him to see that immediate feedback.

We talked about how each of the concepts in a known algorithm could themselves be test-driven as incremental steps (e.g. the use of settled/unsettled collections)--a bit more invasive in terms of encapsulation (and not necessarily; many of these are public, reusable concepts on their own) but potentially very valuable.

He did indicate that his approach to devising new algorithms was "top-down," i.e. he started by trying to dream up the "big picture" and then worry about the degenerate/simple cases later. The opposite of TDD, I guess. He also said that a lot of his work was in script languages (python) and then that got tossed for a more robust implementation for the production system.

Overall the sessions went well and I think he recognizes that there's some potential value. I will take the shortest path algorithm example and hopefully flesh it out and write it up as a blog post down the road.

Jeff

Langr Software Solutions
http://langrsoft.com
http://agileinaflash.com