I think the answers of "solve A first" show succinctly that a large
proportion of minimising refactoring in TDD (and in any code) is
experience ... the sooner you can see these things coming up (before
you code them), the earlier you will approach the problem to avoid
wasting time going down routes that will ultimately be refactored out.

And the analogy with scaffolding for a house is an excellent one -
there is a lot of "stuff" constructed when building a house, *just* to
support the construction - it is then discarded.

2008/5/23 Sriram Gopalan <mgsram@...>:
> I fully agree.
> Solve A. Ideally a & b would be contained within A and you may or may not
> have to refactor them out. May be you would refactor a _c_ out :-). Also
> note that you need to keep the whole test suite green. Therefore, no way you
> could get wrong with the algorithm that is A.
>
> -Sriram
>
> On Thu, May 22, 2008 at 6:59 PM, George Dinwiddie <lists@...>
> wrote:
>
>> Olof Bjarnason wrote:
>> > @Matt, @John and @Ron.
>> >
>> > Say I want to solve a problem A.
>> >
>> > With my experience, I can visualize a solution consisting of two
>> > subproblems a and b, two "helper classes" of A.
>> >
>> > I try to solve a first.
>>
>> Solve A first. Perhaps the a and b you envision will appear in that
>> solution and perhaps not. It surprises me how often not.
>>
>> - George
>>
>> --
>> ----------------------------------------------------------
>> * George Dinwiddie * http://blog.gdinwiddie.com
>> Software Development http://www.idiacomputing.com
>> Consultant and Coach http://www.agilemaryland.org
>> ----------------------------------------------------------
>>
>>
>>
>
> [Non-text portions of this message have been removed]
>
>