As someone has already pointed out, it'll take you a while to really
get fluent in TDD, so you're comparing your existing experience
against a new skill.

In the meantime, here's a recent study from Microsoft

    http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf

"Case studies were conducted with three development teams at Microsoft
and one at IBM that have adopted TDD. The results of the case studies
indicate that the pre-release defect density of the four products
decreased between 40% and 90% relative to similar projects that did
not use the TDD practice. Subjectively, the teams experienced a 15-35%
increase in initial development time after adopting TDD."

S.


On 24 Dec 2008, at 19:29, Brandon Olivares wrote:
> Hi,
>
> So I decided to put an honest effort into trying TDD.
>
> My feeling about it after trying it on a single user story is that
> it's
> really, really useful, and gives a lot of assurance, but is a pain
> to write,
> and increases the time to program significantly. I estimate it
> increased the
> time it took me to program this threefold, from what it would have
> been had
> I not used tests. I had 54 unit tests and 92 functional tests, so it
> definitely was a lot to write.
>
> So my question is, is the benefit gained from doing this, enough to
> offset
> the extra time? I'm really happy with it, because after I wrote
> those tests,
> I was fairly confident I could test it out through the UI myself
> without any
> difficulties, and indeed I could. I'm fairly confident there aren't
> any
> major hidden bugs, unless I missed a very fringe case.
>
> But, it took a long time.
>
> Thoughts?
>
> Thanks,
> Brandon
>

Steve Freeman
http://www.mockobjects.com

Winner of the Agile Alliance Gordon Pask award 2006

Hello, Brandon.  On Wednesday, December 31, 2008, at 6:36:29 AM,
you wrote:

> I'm writing a class now that I'm really not sure how I'm going to implement
> certain parts. Of course, I'm writing each test before implementing it.
> I've read before about not thinking too far in the future, and only writing
> the code that makes the test pass. How literally do you take this? Is it
> wise to try to look in the future to find the best implementation of the
> class, or literally only write as much as is needed to make the test pass
> right now, even if it will be changed later?

I think all the time. I code only what I need right now, in some
simple and clear way.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
The rules are ways of thinking, not ways to avoid thinking.

Hello,
One thing I found useful is to establish some sort of plan through a
list of tests that I order and implement one at a time. Like all plans,
it should be following you, not followed by the letter: changing the
order, removing unnecessary or duplicate tests, adding some more
tests...

And yes, you have to think all the time, because design and code is
one and the same thing.

Regards,
--
Arnaud Bailly, PhD
OQube - Software Engineering

web> http://www.oqube.com

Arnaud Bailly wrote:

> One thing I found useful is to establish some sort of plan through a
> list of tests that I order and implement one at a time. Like all plans,
> it should be following you, not followed by the letter: changing the
> order, removing unnecessary or duplicate tests, adding some more
> tests...

Right: Then you can sort the list and do the items from easy to hard. Subsequent
tests can reuse fixtures invented for the simpler tests.

The goal is each test failure tells you the next valuable thing to do to the
code, in the right order. So even within one test case you can write a missing
method, then write a few assertions, listed in the order you ought to pass them
as you build that method.

--
    Phlip

If the tests have a lot of duplication testing an aspect of a class,
that can mean that you should extract a class to represent that
aspect. Now you have two classes and I would move some of the tests to
a test suite for that new class and remove duplication in them.

Sent from my iPhone

On Dec 31, 2008, at 1:34 PM, "Brandon Olivares" <programmer2188@...
  > wrote:

> Hi,
>
> Thanks so much. This all really helps.
>
> It is difficult, but I am really liking it so far. I don't know yet
> how this
> class will end up implementing the needed functionality, though. I
> just know
> how it passes the tests so far. Quite interesting.
>
> A quick off-topic question: what do you do about repetitive tests?
> Do you
> refactor them, too? I find that many tests end up being repetitive.
>
> Thanks,
> Brandon
>
>> -----Original Message-----
>> From: extremeprogramming@yahoogroups.com
>> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Adam Sroka
>> Sent: Wednesday, December 31, 2008 4:08 PM
>> To: extremeprogramming@yahoogroups.com
>> Subject: Re: [XP] TDD - Planning Ahead
>>
>> On Wed, Dec 31, 2008 at 12:07 PM, Dale Emery <dale@...
>> <mailto:dale%40dhemery.com> > wrote:
>>> Hi Brandon,
>>>
>>> Technically, you could go on faking it indefinitely, but you know
>>> you
>> mean
>>>> to actually do something else with it. For instance if I have a
>> method
>>>> that
>>>> needs to return a count of something, I could return the expected
>> number,
>>>> but I know I really want the count, no matter what it is.
>>>
>>> That's what makes the "refactor" step so important. As you write the
>> code
>>> to pass your second or third or fourth test, you will likely
>> introduce some
>>> repetition or pattern or awkwardness into the code. Once the code
>> passes
>>> the tests, you'll notice that smell and refactor the code to be
>> simpler.
>>>
>>> One trick I've learned is how to select the next test: Select one
>> that
>>> nudges the existing code toward a /little/ more ugliness. Then
>> refactor the
>>> ugliness out. With counts, I find that tests for zero, one, and many
>> items
>>> usually is enough to force just the right amount of ugliness, which
>> in turn
>>> forces the code toward its final form (loop, internally-stored
>>> count,
>>> regular expression). That's three tests, which you can write and
>>> pass
>>> within a few minutes.
>>>
>>
>> Ditto all of the above.
>>
>> You have to know when you are close enough to the "real" answer that
>> you can get there with one small step. That is the trick. It is true
>> that you could go on faking it for a long time. But, as you said the
>> goal is to get to the "real" thing. You just want to lower the
>> resistance enough that you can get there with a small, logical,
>> easily
>> tested change. These are the "baby steps" that Kent Beck talks about.
>>
>> BTW, a similar method has been described as "triangulation". I'm not
>> sure where the term originates, but Dave Astels used it in his book.
>> Basically, you write two tests that expect two different values from
>> the same code. When you write the second implementation to return the
>> second value you will have created duplication which you can refactor
>> out.
>>
>> Another trick is to look for a value that wouldn't naturally come out
>> of the code and test for that in order to force yourself to get the
>> "real" value. This is the approach that I prefer when using mocks.
>> For
>> example, if my initial test checks for zero (or null, nil, undef,
>> whatever your language returns by default) then I might mock
>> something
>> to produce the value "5" and expect that answer in my test. Then I
>> can
>> set my implementation to get it from the right place. You could argue
>> that it is simpler to just return the hardcoded value, but this is a
>> small enough step that I am comfortable.
>>
>>
>>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
> Sent: Thursday, January 01, 2009 2:02 PM
> To: extremeprogramming@yahoogroups.com
> Cc: <extremeprogramming@yahoogroups.com>
> Subject: Re: [XP] TDD - Planning Ahead
>
> If the tests have a lot of duplication testing an aspect of a class,
> that can mean that you should extract a class to represent that
> aspect. Now you have two classes and I would move some of the tests to
> a test suite for that new class and remove duplication in them.
>

Can you explain a bit what you mean? I don't know if I see your point there.
To me, testing has a lot of duplication. I mean you are testing all of the
fringe cases of a method, so you'll be calling each one quite a few times.

Thanks,
Brandon

Brandon

For those who don't know me (my name is quite common and there may be
others, better known than myself, who answer to the same name - speak to
my parents if you wish to complain) I affirmatively believe in Virtual
Collocation. I am of the opinion that working remotely is fair,
practical, and eminently doable in agile development. The only thing it
lacks is a critical mass of favourable opinion.

As it appears that I have been hobbled on another group (maybe I was
speaking off-topic, but I'd beg to differ if I thought it would make a
difference to the outcome) it's probably more appropriate that this
debate be had here.

What are the opinions of this forum? Am I wrong? Can you convince me?

    Owen.

>
> What are the opinions of this forum? Am I wrong? Can you convince me?
>
I think it is more for you to convince us.
I doubt an opinion can easily be declared "wrong", it very much
depends on the situation at hand. Is virtual collocation inferior to
"true" collocation, yes it absolutely is.

-d

--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

Hi Owen,

> For those who don't know me (my name is quite common and
> there may be others, better known than myself, who answer to
> the same name - speak to my parents if you wish to complain)
> I affirmatively believe in Virtual Collocation. I am of the
> opinion that working remotely is fair, practical, and
> eminently doable in agile development. The only thing it
> lacks is a critical mass of favourable opinion.

That's a surprising statement, given the number of companies
I know of with distributed teams. But I'll take it that you
mean "among advocates of exteme programming." :-)

It's clear that we have to deal with distribution, since it
is so widely practiced, but I don't think it's simply a
matter of "critical mass of favourable opininion." Rather,
I'd suggest that we simply don't yet know how to do it well.

I've worked with collocated and distributed teams and it's
clear to me that the collocated groups, on average, did a
better job of communication and working together. If you
have specific techniques to overcome the handicaps that
come from working in a distributed environment, I for
one would be very glad to learn about them. I'm hoping
they won't all be technical solutions though. :-(

Charlie

On Thu, Jan 1, 2009 at 5:53 PM, Owen Thomas <owen.paul.thomas@...> wrote:
> For those who don't know me (my name is quite common and there may be
> others, better known than myself, who answer to the same name - speak to
> my parents if you wish to complain) I affirmatively believe in Virtual
> Collocation. I am of the opinion that working remotely is fair,
> practical, and eminently doable in agile development. The only thing it
> lacks is a critical mass of favourable opinion.
>
> As it appears that I have been hobbled on another group (maybe I was
> speaking off-topic, but I'd beg to differ if I thought it would make a
> difference to the outcome) it's probably more appropriate that this
> debate be had here.
>
> What are the opinions of this forum? Am I wrong? Can you convince me?
>

If I weren't collocated with my team, I would miss the following things:

1) The ability to hear what others in the room were talking about
including relevant technical conversations, camaraderie, and idle
banter. I would only get to hear what they typed in the chat window,
which, even on a quiet day, is 10% or less of the available
information.

2) The ability to let others know what I am doing/thinking, without
having to specifically track them down. Plus, if I say something out
loud I can be pretty sure those around me heard it. If I type it in a
window it is easier to miss or ignore.

3) Focus. There is a comparative lack of non-work related distractions
and an element of peer pressure/accountability. For example: right now
Virginia Tech is playing Cincinnati on the TV; my guitar is sitting on
the other side of the room, and I have some stuff I would like to work
on; my roommate isn't here, but if he were there are a few things I
need to talk to him about...

If I were at work, even if I had access to a TV, guitar, video games,
etc. I wouldn't partake because: a) my environment provides a
purposeful focus and b) I would worry about what others thought.

4) People outside my immediate team wouldn't know where I was and
would be less likely to come to me with questions, ideas, etc.

That's just off the top of my head. I'm sure there are other things I
would miss.

Not to mention, there is just a psychological advantage to being in a
situation where I have to interact with people throughout the course
of the day. When I spend the day alone, even if I am writing emails
and sending IMs, I just don't feel as good as I do when there are
other people around. There is something about frequent social
interaction that just makes me feel better and stronger as a person.

I think working remotely is not 'fair or practical or doable' - it is the
real world. A business runs because of the economies of that business,
nothwithstanding its internal processes (or lack thereof). To that end, if
there are compelling reasons to geo-locate or time-locate teams, that will
happen and internal production processes shall be required to support it.

So, the question is not whether virtual colocation is better, or something
else is. The fact is: remote collaboration as a business model makes sense
for a certain class of problems, and is here to stay, whether we like it or
not. So, how can our processes evolve to address need of the hour ?

regards,
Tathagat

http://managewell.net


On Fri, Jan 2, 2009 at 7:23 AM, Owen Thomas <owen.paul.thomas@...>wrote:

>   For those who don't know me (my name is quite common and there may be
> others, better known than myself, who answer to the same name - speak to
> my parents if you wish to complain) I affirmatively believe in Virtual
> Collocation. I am of the opinion that working remotely is fair,
> practical, and eminently doable in agile development. The only thing it
> lacks is a critical mass of favourable opinion.
>
> As it appears that I have been hobbled on another group (maybe I was
> speaking off-topic, but I'd beg to differ if I thought it would make a
> difference to the outcome) it's probably more appropriate that this
> debate be had here.
>
> What are the opinions of this forum? Am I wrong? Can you convince me?
>
> Owen.
>
>
>


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

On Thu, Jan 1, 2009 at 8:07 PM, Tathagat Varma <tathagat.varma@...> wrote:
> I think working remotely is not 'fair or practical or doable' - it is the
> real world. A business runs because of the economies of that business,
> nothwithstanding its internal processes (or lack thereof). To that end, if
> there are compelling reasons to geo-locate or time-locate teams, that will
> happen and internal production processes shall be required to support it.
>
> So, the question is not whether virtual colocation is better, or something
> else is. The fact is: remote collaboration as a business model makes sense
> for a certain class of problems, and is here to stay, whether we like it or
> not. So, how can our processes evolve to address need of the hour ?
>

For starters I think we should inform management about the downsides
so that they can make an informed decision. Ron Jeffries pointed out
this study on another thread:
http://www.sciencedaily.com/releases/2000/12/001206144705.htm

Second, we need to come up with techniques that will mitigate the loss
of productivity that the study indicates. Others have had some luck
with remote pair programming. Are there other techniques that can
help?

Hi Owen,

What do you mean by Virtual Collocation?

Personally, I have been happily working in what I consider to be an agile
fashion, on and off for over 5 years, with a group on the other side of the
world (me in UK, them in Australia).

I would describe this as distributed working. How is Virtual Collocation
different. It sounds like I would get non of the benefits of collocation
combined with non of the benefits of distributed working? What am I missing?

I love that I can choose my work locations with great views and good coffee
instead of some corporate block or office park.

However, with this team we don't even try XP collocation practices like pair
programming. While there are tools for this they miss the most fundamental
problem of significantly distributed teams - timezones. While I can make and
take telephone calls at any time of day, my optimum time for programming is
my optimum time for programming.

At the same time, I'm not sure if I recommend this. Our situation works
because we have known each other so long we act more like friends than
colleagues (this gives more slack when things are not going well), and have
spent a lot of time physically working together in various roles.

For new teams, I think physical collocation is very important until the team
has gone through its SNP cycles. If nothing else, when things get crappy you
need to all be able to say "screw this, lets go get a coffee" and remind one
another that you are actually a human beings.

Are you aware of 37signals? They are an organization I would consider very
agile and exceptionally successful, but are big advocates of remote working.


Cheers,

Craig


2009/1/2 Owen Thomas <owen.paul.thomas@...>

> For those who don't know me (my name is quite common and there may be
> others, better known than myself, who answer to the same name - speak to
> my parents if you wish to complain) I affirmatively believe in Virtual
> Collocation. I am of the opinion that working remotely is fair,
> practical, and eminently doable in agile development. The only thing it
> lacks is a critical mass of favourable opinion.
>
> As it appears that I have been hobbled on another group (maybe I was
> speaking off-topic, but I'd beg to differ if I thought it would make a
> difference to the outcome) it's probably more appropriate that this
> debate be had here.
>
> What are the opinions of this forum? Am I wrong? Can you convince me?
>
>   Owen.
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>
>


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

Hello David.

--- In extremeprogramming@yahoogroups.com, "David H." <dmalloc@...>
wrote:

> I doubt an opinion [in favour of collocation] can easily be declared
"wrong", it very much
> depends on the situation at hand.

You're right. But an hypothesis can be proven false, so I'll try to
rephrase what I want to know:
Is there a relationship between the physical proximity of team members
and overall software quality that cannot be overcome with ICT?
This might lead one to have to define what productivity will be. I
believe that defining quality in software development creates a paradox
when one considers that a lot of what we make is used in subsequent
development cycles. The process philosophy used to design component
software tools will create such component tools that can best be used in
a similar development process.

> Is virtual collocation inferior to
> "true" collocation, yes it absolutely is.

I have to admit that I don't believe you. That's a bold statement to
make, I know. I make it because inferior lacks a definition that is
acceptable to me.

    Owen.



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

Hello Charlie

--- In extremeprogramming@yahoogroups.com, "Charlie Poole" <charlie@...>
wrote:

> That's a surprising statement, given the number of companies
> I know of with distributed teams. But I'll take it that you
> mean "among advocates of exteme programming." :-)

Well, it is my experience that with maybe a few random exceptions, I
haven't seen any employment opportunities. I could be looking in the
wrong places. My criteria is that I would like to look for a permanent,
salaried role as a developer extending into designer if there were any
such openings in the project(s) I would be working on.

> I'd suggest that we simply don't yet know how to do it well.

I believe this is the truth of the matter. Still, it is apparent that
others would like to differ.

> If you
> have specific techniques to overcome the handicaps that
> come from working in a distributed environment, I for
> one would be very glad to learn about them. I'm hoping
> they won't all be technical solutions though. :-(

I do in fact happen to have a few thoughts of my own. They are slightly
technical because they do require a software system to be built. However
in terms of complexity, the software system is very scalable. Contact me
privately if you want to know more.

I don't think I'm all that good at "non-technical" solutions. :)

    Owen.

Hi Adam.

If I'm not mistaken, you were contributing to the discussion I was
having elsewhere. Thanks for taking up the conversation here.

I believe point 1 can be overcome by a suitably configured VOIP system.
Points 2 and 4 likewise have a solution. In fact, the idea that I have
may provide a simultaneous solution to these three points. Message me
privately if you want to know more.

Point 3 is a question of the exercise of discipline, and so is not the
exclusive preserve of the software development industry.

As for psychological advantages, several that can be realised by working
where you live are that you have more opportunity to interact with your
family and friends, and greater choice as to the type of environment to
dwell in. I think there are clear advantages to the environment itself.

    Owen.

--- In extremeprogramming@yahoogroups.com, "Adam Sroka" <adam.sroka@...>
wrote:
>
> On Thu, Jan 1, 2009 at 5:53 PM, Owen Thomas owen.paul.thomas@...
wrote:
> > For those who don't know me (my name is quite common and there may
be
> > others, better known than myself, who answer to the same name -
speak to
> > my parents if you wish to complain) I affirmatively believe in
Virtual
> > Collocation. I am of the opinion that working remotely is fair,
> > practical, and eminently doable in agile development. The only thing
it
> > lacks is a critical mass of favourable opinion.
> >
> > As it appears that I have been hobbled on another group (maybe I was
> > speaking off-topic, but I'd beg to differ if I thought it would make
a
> > difference to the outcome) it's probably more appropriate that this
> > debate be had here.
> >
> > What are the opinions of this forum? Am I wrong? Can you convince
me?
> >
>
> If I weren't collocated with my team, I would miss the following
things:
>
> 1) The ability to hear what others in the room were talking about
> including relevant technical conversations, camaraderie, and idle
> banter. I would only get to hear what they typed in the chat window,
> which, even on a quiet day, is 10% or less of the available
> information.
>
> 2) The ability to let others know what I am doing/thinking, without
> having to specifically track them down. Plus, if I say something out
> loud I can be pretty sure those around me heard it. If I type it in a
> window it is easier to miss or ignore.
>
> 3) Focus. There is a comparative lack of non-work related distractions
> and an element of peer pressure/accountability. For example: right now
> Virginia Tech is playing Cincinnati on the TV; my guitar is sitting on
> the other side of the room, and I have some stuff I would like to work
> on; my roommate isn't here, but if he were there are a few things I
> need to talk to him about...
>
> If I were at work, even if I had access to a TV, guitar, video games,
> etc. I wouldn't partake because: a) my environment provides a
> purposeful focus and b) I would worry about what others thought.
>
> 4) People outside my immediate team wouldn't know where I was and
> would be less likely to come to me with questions, ideas, etc.
>
> That's just off the top of my head. I'm sure there are other things I
> would miss.
>
> Not to mention, there is just a psychological advantage to being in a
> situation where I have to interact with people throughout the course
> of the day. When I spend the day alone, even if I am writing emails
> and sending IMs, I just don't feel as good as I do when there are
> other people around. There is something about frequent social
> interaction that just makes me feel better and stronger as a person.
>

Hello Craig.

--- In extremeprogramming@yahoogroups.com, "Craig Davidson"
<craigmdavidson@...> wrote:
> What do you mean by Virtual Collocation?

Off the top of my head... :)

My definition of a Virtually Collocated team is one which relies on ICT
to participate in a collaborative endeavour of arbitrary complexity. It
would engage multiple ICT media as necessary to maximise the speed and
relevance of knowledge transfer.

> Personally, I have been happily working in what I consider to be an
agile
> fashion, on and off for over 5 years, with a group on the other side
of the
> world (me in UK, them in Australia).

I'm from Wollongong.

So this team is physically collocated yes? Your situation would not
accord with my definition of Virtual Collocation.

> I would describe this as distributed working. How is Virtual
Collocation
> different. It sounds like I would get non of the benefits of
collocation
> combined with non of the benefits of distributed working? What am I
missing?

See the above definition. I'd like to know if I'm missing anything.

> I love that I can choose my work locations with great views and good
coffee
> instead of some corporate block or office park.

I have a similar opinion about how I want the rest of my life to work
with my interest in software development.

> Are you aware of 37signals? They are an organization I would consider
very
> agile and exceptionally successful, but are big advocates of remote
working.

I am now. Thank you very much for the lead. I shall take a look.

    Owen.

Thursday, January 01, 2009, 11:56:02 PM, Owen Thomas wrote:

>> 1) The ability to hear what others in the room were talking about
>> including relevant technical conversations, camaraderie, and idle
>> banter. I would only get to hear what they typed in the chat window,
>> which, even on a quiet day, is 10% or less of the available
>> information.

> I believe point 1 can be overcome by a suitably configured VOIP system.

While this may be true, I've never worked with any remote
audio communication system that works well for this kind of
"overhearing the important parts of conversations around me".
I believe the reason is that I lose directionality.

When I am in a room with a team working around me, I can pick
up threads of conversations as they're going on. If I hear a
word or phrase that seems important to me, I can "perk up my
ears" for that specific conversation. I slightly alter the
direction my head is oriented and it becomes much easier to
pick out the specific conversation among the other two or
three conversations going on in the room. I can do this nearly
seamlessly while continuing to effectively pair with my
partner. If I want to contribute to the converstaion, I simply
excuse myself from my pair and move my body closer so I can
contribute.

When I am over a remote audio connection, it's much more
difficult to pick out any specific conversation. When I do
concentrate on a background conversation it takes
significantly more effort than when in the room, and easily
disrupts the work my partner and I are doing. If I want to
contribute to the other pair's discussion, I have to either
have my partner intervene on my behalf, or attempt to insert
myself via IM.

The remote connection doesn't give me, the listener, any good
way to adjust "what" I'm listening to; the microphone on the
other end is in control.

I can imagine sophisticated remote audio gear that let me
primarily participate in one conversation with my partner,
while being able to monitor other team conversations in
the background and easily switch to participating in one of
them. But, I've never seen such a setup.


--

  Doug Swartz

On Thu, Jan 1, 2009 at 9:56 PM, Owen Thomas <owen.paul.thomas@...> wrote:
> Hi Adam.
>
> If I'm not mistaken, you were contributing to the discussion I was
> having elsewhere. Thanks for taking up the conversation here.
>
> I believe point 1 can be overcome by a suitably configured VOIP system.

Two things. First, in the type of workspace that we (XP teams) prefer
there is a lot going on and a lot of information that can be picked up
in the background. More, even than in a typical office scenario.
Because, everyone is in the same room in close proximity and everyone
is working in pairs. So, you get very direct and timely information
from the pair you are working with, but you also pick up on things
that other pairs are discussing. In order for a VOIP system to
approximate this you would need to be able to listen to everyone
simultaneously and adjust the volumes individually so that you could
hear your pair's channel most clearly. This seems infeasible.

Second, even if you could create the appropriate "conference call"
setup that doesn't necessarily mean that people will communicate in
the same way. Being on the phone is very different from talking to a
person in the same room. It feels different, and people act
accordingly.

> Points 2 and 4 likewise have a solution. In fact, the idea that I have
> may provide a simultaneous solution to these three points. Message me
> privately if you want to know more.
>
> Point 3 is a question of the exercise of discipline, and so is not the
> exclusive preserve of the software development industry.
>

I don't agree that it "is a question of the exercise of discipline."
One of the reasons people go to an office to work is that it gives
them an environment that is conducive to doing their work. This
includes the elimination of outside distractions, the appropriate
tools and facilities, and proximity to coworkers.

> As for psychological advantages, several that can be realised by working
> where you live are that you have more opportunity to interact with your
> family and friends, and greater choice as to the type of environment to
> dwell in. I think there are clear advantages to the environment itself.
>

If I spend more time "interacting with family and friends" I am not in
fact working. Thus, my point about focus. If I want more time with
family and friends that time should be outside the time that I am
working.

Having an environment that is both comfortable to live in and
conducive to work sounds expensive. In my case, at the very least, I
would need a totally separate room. In this part of town that would
cost me about $500 a month. That's before I consider equipment and
furnishings. Maybe I can find a clever way to lower my tax burden or
even to get my employer to pay for a portion of that, but there is
still going to be a significant out-of-pocket expense (My employer
isn't going to front the whole cost of me moving out of a shared
two-bedroom into my own two-bedroom or a shared three-bedroom house.)

On Thu, Jan 1, 2009 at 9:07 PM, Tathagat Varma <tathagat.varma@...> wrote:
> I think working remotely is not 'fair or practical or doable' - it is the
> real world. A business runs because of the economies of that business,
> nothwithstanding its internal processes (or lack thereof). To that end, if
> there are compelling reasons to geo-locate or time-locate teams, that will
> happen and internal production processes shall be required to support it.
>
> So, the question is not whether virtual colocation is better, or something
> else is. The fact is: remote collaboration as a business model makes sense
> for a certain class of problems, and is here to stay, whether we like it or
> not. So, how can our processes evolve to address need of the hour ?

One practice that ameliorates to some extent the
communication/collaboration deficiencies of remote team work is to
collocate the whole team for the first week or so of the project.
This helps establish a shared mental model as well as rapport and
trust.

Of course, there is often resistance to doing this, usually because it
decreases the cost savings of distribution.

Steven Gordon

>
> regards,
> Tathagat
>
> http://managewell.net

Michael Feathers and I are working up a talk that will be a review of
effectively 10 years of TDD. The idea is partly just to look at the
history, but mainly to consider what we've learned over all this time.

We'd like all of you to do our work for us by helping to construct a
time line. I've started a page on the C2 wiki with some strawman
entries to get people riled up so that they'll contribute.

http://c2.com/cgi/wiki?TenYearsOfTestDrivenDevelopment

Please join in.

Thanks

S.


Steve Freeman
http://www.mockobjects.com

Winner of the Agile Alliance Gordon Pask award 2006

2009/1/2 Steve Freeman <smgfreeman@...>:
> Michael Feathers and I are working up a talk that will be a review of
> effectively 10 years of TDD. The idea is partly just to look at the
> history, but mainly to consider what we've learned over all this time.
>

Might I suggest http://www.dipity.com/ for that? It will help you
create a visual representation and you can link in third party
content.

-d


--
Sent from gmail so do not trust this communication.
Do not send me sensitive information here, ask for my none-gmail accounts.

"Therefore the considerations of the intelligent always include both
benefit and harm." - Sun Tzu

> Michael Feathers and I are working up a talk that will be a review of
> effectively 10 years of TDD. The idea is partly just to look at the
> history, but mainly to consider what we've learned over all this time.

When was Rails launched? It's a "first" for a GUI platform invented _via_ TDD,
without it strapped on as an afterthought...

I have an example of a large method in my article here:
<http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=75>

Pretend the large method in Figure 1 was created by TDD with
insufficient refactoring. There would be a large number of tests for
that method, reflecting the large amount of behavior in that method.
The article describes several extract methods that can be done. And
points out some Move Method refactorings to correct a Feature Envy
code smell -- moving some methods out of the nsAccessibleText class
into the class nsISelectionController.

If you were test-driving nsAccessibleText, and now fixing code smells,
you might have created the class nsISelectionController just to move
the methods into it. I would move some of those tests that drove the
creation of the code that we did Move Method on into a test-suite for
nsISelectionController.

As the article continues, we observe that BackupOldSettings and
RestoreOldSettings are being used to save and restore some data
belonging to the class nsISelectionController, but the class doing
this work is nsAccessibleText. This is an Inappropriate Intimacy code
smell, and one way to fix it is to use the Memento design pattern.
Again we have created a new class [possibly an "inner class"], and we
can maybe move some tests from the original class test-suite to
another one.

And we observe that several methods have two parameters that always go
together - aStartOffsetand and aEndOffset. Data Clump code smell. Move
those into a new "Range" class and extract and move methods like
"Length" into that class and again there could be an opportunity to
not only remove duplication in the code, but also in tests that may
have been testing that several methods computed length or other
functionality that belongs in Range.

The examples from this article came from un-tdd'ed legacy code with
very few unit tests, but I have seen people new to TDD ignore the same
code smells when test-driving a class. The code-smells were not just
in the production code, but also in the extreme duplication of the
test code, and the fixes were to remove duplication in both the
production code (by extracting methods and classes) and the tests.

Jay Flowers wrote a blog entry about TDD smells here
  <http://jayflowers.com/WordPress/?p=89>
    "Looking at this now I think I went to great lengths to make the
test look simple, to cover up the complexity [...]"
    "So what grabs you by the nose and leads to tight coupling?  I
don't know yet. Maybe looking at motivations will help.  I was
motivated to perform this refactoring because [...]   I think we can
pull these smells out:
   * Slow Tests
   * Lengthy SetUp
   * Lengthy TearDown
   * Asynchronous Test
   * Party Crasher
  "Two of those smells have already been identified by Gerard and are
documented in xUnit Patterns."

On Thu, Jan 1, 2009 at 12:27 PM, Brandon Olivares
<programmer2188@...> wrote:
>
>
>> -----Original Message-----
>> From: extremeprogramming@yahoogroups.com
>> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
>> Sent: Thursday, January 01, 2009 2:02 PM
>> To: extremeprogramming@yahoogroups.com
>> Cc: <extremeprogramming@yahoogroups.com>
>> Subject: Re: [XP] TDD - Planning Ahead
>>
>> If the tests have a lot of duplication testing an aspect of a class,
>> that can mean that you should extract a class to represent that
>> aspect. Now you have two classes and I would move some of the tests to
>> a test suite for that new class and remove duplication in them.
>>
>
> Can you explain a bit what you mean? I don't know if I see your point there.
> To me, testing has a lot of duplication. I mean you are testing all of the
> fringe cases of a method, so you'll be calling each one quite a few times.
>
> Thanks,
> Brandon
>
> Brandon
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>
>



--
C. Keith Ray, IXP Coach, Industrial Logic, Inc.
http://industriallogic.com      866-540-8336 (toll free)
Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
http://agilesolutionspace.blogspot.com/

On Fri, Jan 2, 2009 at 8:26 AM, Phlip <phlip2005@...> wrote:
>> Michael Feathers and I are working up a talk that will be a review of
>> effectively 10 years of TDD. The idea is partly just to look at the
>> history, but mainly to consider what we've learned over all this time.
>
> When was Rails launched?

July 2004.

It's a "first" for a GUI platform invented _via_
> TDD,
> without it strapped on as an afterthought...

Although I agree Rails is notable for being one of the first to have a
unit test framework baked in, I'm not sure that it's the first example
of a test-driven GUI. Either way, it does belong on the timeline.

Adam Sroka wrote:

> Although I agree Rails is notable for being one of the first to have a
> unit test framework baked in, I'm not sure that it's the first example
> of a test-driven GUI. Either way, it does belong on the timeline.

The ideal would be TDD used to invent the entire stack - the display drivers,
the GUI toolkit widgets, the presentation system, the scripting language, and
the high-end frameworks.

What Rails did was apply TDD on top of klutzy, TDD-hostile systems - HTML, HTTP,
and JavaScript. You don't have to build your own mock servers and stuff. If you
don't waste time baking your own bricks on-site, the entry barriers to TDD are
much lower.

So Rails has converted one of the hardest TDD situations into one of the
easiest.

--
    Phlip

In our sprints I have a QA person manually testing bits of functionality as
they are delivered;  This generates defects as we go and we've been adding a
task to the Sprint backlog for each defect.  I'm not completely satisfied
with this approach, so I am asking what other, more experienced folks are
doing with defects.
Thanks,

--
http://mikeonitstuff.net/  New Blog
http://mikeonitstuff.com/  Old Blog
http://mikeonbikes.blogspot.com/


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

Well, I'm pretty old. I would recommend creating automated tests that
fail because of the defect, and these tests would have to fail for the
task to be acceptable at the end of the sprint.

Think about how the functionality accumulates with each sprint - there
will be soon no time for manual re-testing of previously implemented
functionality. Without test automation, there could be undetected
regressions.

Some dialogs with the tester, development team and product owners may
result in a "defect" being classified as a new backlog item, to be
implemented a later sprint. This is particularly relevant for
"missing" functionality.


On Fri, Jan 2, 2009 at 8:59 AM, Mike Coon <mcoon1961@...> wrote:
> In our sprints I have a QA person manually testing bits of functionality as
> they are delivered;  This generates defects as we go and we've been adding a
> task to the Sprint backlog for each defect.  I'm not completely satisfied
> with this approach, so I am asking what other, more experienced folks are
> doing with defects.
> Thanks,
>
> --
> http://mikeonitstuff.net/  New Blog
> http://mikeonitstuff.com/  Old Blog
> http://mikeonbikes.blogspot.com/
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.comYahoo! Groups Links
>
>
>
>



--
C. Keith Ray, IXP Coach, Industrial Logic, Inc.
http://industriallogic.com      866-540-8336 (toll free)
Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
http://agilesolutionspace.blogspot.com/

correctIon:  "... these tests would have to PASS for the task to be
acceptable at the end of the sprint."

On Fri, Jan 2, 2009 at 9:08 AM, Keith Ray <keith.ray@...> wrote:
> Well, I'm pretty old. I would recommend creating automated tests that
> fail because of the defect, and these tests would have to fail for the
> task to be acceptable at the end of the sprint.
>
> Think about how the functionality accumulates with each sprint - there
> will be soon no time for manual re-testing of previously implemented
> functionality. Without test automation, there could be undetected
> regressions.
>
> Some dialogs with the tester, development team and product owners may
> result in a "defect" being classified as a new backlog item, to be
> implemented a later sprint. This is particularly relevant for
> "missing" functionality.
>
>
> On Fri, Jan 2, 2009 at 8:59 AM, Mike Coon <mcoon1961@...> wrote:
>> In our sprints I have a QA person manually testing bits of functionality as
>> they are delivered;  This generates defects as we go and we've been adding a
>> task to the Sprint backlog for each defect.  I'm not completely satisfied
>> with this approach, so I am asking what other, more experienced folks are
>> doing with defects.
>> Thanks,
>>
>> --
>> http://mikeonitstuff.net/  New Blog
>> http://mikeonitstuff.com/  Old Blog
>> http://mikeonbikes.blogspot.com/
>>
>>
>> [Non-text portions of this message have been removed]
>>
>>
>> ------------------------------------
>>
>> To Post a message, send it to:   extremeprogramming@eGroups.com
>>
>> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>>
>> ad-free courtesy of objectmentor.comYahoo! Groups Links
>>
>>
>>
>>
>
>
>
> --
> C. Keith Ray, IXP Coach, Industrial Logic, Inc.
> http://industriallogic.com      866-540-8336 (toll free)
> Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
> http://agilesolutionspace.blogspot.com/
>



--
C. Keith Ray, IXP Coach, Industrial Logic, Inc.
http://industriallogic.com      866-540-8336 (toll free)
Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
http://agilesolutionspace.blogspot.com/

On Fri, Jan 2, 2009 at 8:50 AM, Phlip <phlip2005@...> wrote:
> Adam Sroka wrote:
>
>> Although I agree Rails is notable for being one of the first to have a
>> unit test framework baked in, I'm not sure that it's the first example
>> of a test-driven GUI. Either way, it does belong on the timeline.
>
> The ideal would be TDD used to invent the entire stack - the display
> drivers,
> the GUI toolkit widgets, the presentation system, the scripting language,
> and
> the high-end frameworks.
>

I don't know about display drivers. Those are so tied to the hardware.
It's hard enough to get vendors to open source that code, let alone
asking them to test-drive it. It might be nice, but I'm not holding my
breath. Plus, I'm fairly confident that I, personally, will never have
to write those ;-) Otherwise, I'm right with you.

> What Rails did was apply TDD on top of klutzy, TDD-hostile systems - HTML,
> HTTP,
> and JavaScript. You don't have to build your own mock servers and stuff. If
> you
> don't waste time baking your own bricks on-site, the entry barriers to TDD
> are
> much lower.
>
> So Rails has converted one of the hardest TDD situations into one of the
> easiest.
>

Okay. I see what you mean now.

Actually, testing HTML and HTTP was always quite easy in Ruby (and
before it, Perl) even before Rails came along. It is a pain in the ass
in some other languages - Java for instance, but that is because they
insist on using heavy-handed XML techniques to parse/generate HTML and
the servlet API to handle HTTP.

The crappy thing about testing web GUIs is that the output is just
text. What we really care about is how the browser interprets that
text, and Rails doesn't really solve that problem (Though if you
combine it with something like Selenium or Firewatir you can get
there. And, now there is FireUnit which *rules*.)

Rails makes a lot of things easy, and TDD is certainly one of them. On
the other hand, Rails also makes it easy for those who don't like to
test to get away with saying, "We have unit tests." Even though the
only tests they have are the stubs that the framework generates, which
they never touch. I have found this amusing, but also annoying.