Discussion of the eXtreme Programming practice of TestDrivenDevelopment

mpnalvin | 24 Jan 2012 03:25

Picon

Getting the mindset

Hi all! I have several years of experience in traditional development, but I'm trying to adapt to a TDD
approach. The trouble is, I can't get the mindset right. I believe I understand the methodology, and I have
several good books to refer to, but here's what happens.
I start off thinking "OK, got to write that first test. What should it be?" Then I get a design idea. Then my
brain gets excited. It doesn't want to write the test; it wants to follow the idea. It heads off at speed down
the trail, throwing up design candidates, creating interfaces, throwing in the odd pattern etc. as fast
as I can scribble. I try to say to my brain "Bad brain! You are not allowed to think about this. The design
needs to emerge from the test cases." But honestly, cutting off that flow of potentially fruitful ideas
and forcing myself back to the business of plodding along one test at a time reminds me of Douglas Adam's
description of drinking a pan-galactic gargleblaster. Is this just how it is when you start TDD? Am I
addicted to design? :)

I have read some TDD books ("Growing Object-Oriented Software" comes to mind) where there does seem to be
some level of design up front and initial tests serve to validate the architecture. I would love to hear
from those of you who have succeeded in adapting to TDD how you find the design emerging. Do you have a
broad-brush solution up front, using TDD to get the low-level details right, or do you go into TDD with
nothing more than an initial user story and no design in mind?

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/testdrivendevelopment/join

(Continue reading)

Dale Emery | 24 Jan 2012 08:27

Re: Getting the mindset

Hi Mark,

> Hi all! I have several years of experience in traditional development, but I'm trying to adapt to a TDD
approach. The trouble is, I can't get the mindset right.
> 
You haven't got the mindset right... yet.

> I believe I understand the methodology, and I have several good books to refer to, but here's what happens.
> I start off thinking "OK, got to write that first test. What should it be?" Then I get a design idea. Then my
brain gets excited. It doesn't want to write the test; it wants to follow the idea. It heads off at speed down
the trail, throwing up design candidates, creating interfaces, throwing in the odd pattern etc. as fast
as I can scribble. I try to say to my brain "Bad brain! You are not allowed to think about this. The design
needs to emerge from the test cases."
> 
Don't beat yourself up about it. You're allowed to think about design. And when you're done with that, set
your design aside. Write one test. Write the code that passes that one test. Clean up the code. Then write
another test...

If you get design ideas along the way, scribble away. Then set them aside. Write another test.

> But honestly, cutting off that flow of potentially fruitful ideas and forcing myself back to the business
of plodding along one test at a time reminds me of Douglas Adam's description of drinking a pan-galactic
gargleblaster. Is this just how it is when you start TDD? Am I addicted to design? :)
> 
You might be addicted to design. That's not so bad. The trouble is (from the POV of wanting to learn TDD) that
you aren't yet addicted to tests.

So indulge your addiction for now. Design away. Then set your design ideas aside.

And notice that there are additional ways to design, ways that you aren't addicted to yet: Writing a test is

(Continue reading)

mpnalvin | 24 Jan 2012 21:52

Picon

Re: Getting the mindset

Dale,

Thanks so much for this reply. Honestly, I think it has been more helpful to me in terms of developing the
right mindset than any of the books I've read. You're certainly right about me not being addicted to
testing. Even writing that phrase causes an involuntary shudder. But it's precisely this view of testing
as "the drudgery that comes after coding" that I want to change, and the remaking of test writing into part
of the design process is what I find most promising about TDD.

> And notice that there are additional ways to design, ways that you aren't addicted to yet: Writing a test is
an act of design. Writing the code that passes the test is an act of design. Cleaning up code is an act of design.

This is wonderful! My first reaction on reading it was to think "yes, writing tests and code are acts of
design, but they are acts of implementing design rather than creating it." But on further reflection, I
think you are spot on. Even without TDD, I've found the distinction between design and coding to be more of a
project planning concept that a programming reality. In practice, I find a sort of Hegelian dialect where
I express design as a set of ideas, then express those ideas in code, and find that the concrete
implementation modifies the original design concept leading to a synthesis of the two. Is that akin to
what you mean by testing and coding as "acts of design"?

I am wondering if I have been misled slightly by the "emergent design" metaphor. Emergent properties like
the solidity of a table obviously do simply pop up as a result of underlying atomic properties with no
organizing concept. That is truly "bottom-up." But, at least the way I've worked in the past, the end
product of programming results from a succession of syntheses between idea and expression, iterated to a
point of convergence with requirements. And actually, I suppose it doesn't matter whether I start
top-down with the idea, or bottom-up with the expression, so long as both idea and expression are
involved. Sorry. I'm thinking out loud here. Bad habit :)

> Eventually I learned that every refactoring is about coupling, cohesion, understandability, or some
combination of those. That is, every refactoring focuses on the same things that design-in-the-large

(Continue reading)

Charlie Poole | 24 Jan 2012 08:29

Picon

Re: Getting the mindset

Hi,

Writing tests is not an alternative to following your design ideas, it's a
different
way to follow those ideas. Don't try to turn your brain off. Rather, train
yourself
to _implement_ your design ideas by writing tests and then making them pass.

Charlie

On Mon, Jan 23, 2012 at 6:25 PM, mpnalvin <markpaters <at> gmail.com> wrote:

> **
>
>
> Hi all! I have several years of experience in traditional development, but
> I'm trying to adapt to a TDD approach. The trouble is, I can't get the
> mindset right. I believe I understand the methodology, and I have several
> good books to refer to, but here's what happens.
> I start off thinking "OK, got to write that first test. What should it
> be?" Then I get a design idea. Then my brain gets excited. It doesn't want
> to write the test; it wants to follow the idea. It heads off at speed down
> the trail, throwing up design candidates, creating interfaces, throwing in
> the odd pattern etc. as fast as I can scribble. I try to say to my brain
> "Bad brain! You are not allowed to think about this. The design needs to
> emerge from the test cases." But honestly, cutting off that flow of
> potentially fruitful ideas and forcing myself back to the business of
> plodding along one test at a time reminds me of Douglas Adam's description
> of drinking a pan-galactic gargleblaster. Is this just how it is when you
> start TDD? Am I addicted to design? :)

(Continue reading)

Steven Gordon | 24 Jan 2012 10:04

Picon

Re: Getting the mindset

Mark,

It occurs to me that maybe you are trying to do TDD bottom-up (like most,
if not all, of the articles and books do), but do design top-down like I
do.

Bottom up works well after you already have a rough design in mind and you
have enough experience to guess where to start at the bottom to realize
that design.  Of course, you will find that the design you had in mind gets
refined and improved by using TDD to implement it, and then improved
further after refactoring it more when the code works as a whole.

I found what helped me was to TDD top-down by doing the following
(recursively):

1. writing a simple test for the highest-level object.

2. writing the simplest code to attempt to make that test pass via
delegation to lower-level objects that may or may not even exist yet.

3. that test would of course not pass yet until those lower-level objects
would exist, so I would push the previous test on a "stack", and recurse
(i.e., do steps 1 though 5 for each required method of each new class I
just invented).

4. when all the required methods for the delegated classes are complete
enough, make this test pass.

5. REFACTOR!

(Continue reading)

mpnalvin | 24 Jan 2012 22:11

Picon

Re: Getting the mindset

Steven,

The method you outlined is almost exactly what I had in mind (in my case, derived from the "Growing
Object-Oriented Software" book). GOOS calls it "outside-in" programming, since you effectively
follow the message trail from the highest level down to the lowest. The "top-down" nature of the approach
was a a big factor for me. One thing I'm trying to do is to understand the different types of TDD approaches.
I'd call yours "top-down, depth-first" since you use recursion and a stack :) GOOS, on the other hand, uses
Mocks, so it's more "top-down, breadth-first." I don't know enough to have a strong feeling either way
about Mocks, but I'm going to try them and see whether I like the results.

One thing that GOOS does that I found significant is that they start with an acceptance-level (end-to-end)
test. I thought this was an interesting approach since they are then able to derive a system more-or-less
directly from the driving user story. This may be why they call their approach "outside-in" rather than
just "top-down." When you mentioned that you start with the highest-level object, would your initial
tests be acceptance tests, or do you tackle acceptance tests a different way?

Thanks!

Mark

--- In testdrivendevelopment <at> yahoogroups.com, Steven Gordon <sgordonphd <at> ...> wrote:
>
> Mark,
> 
> It occurs to me that maybe you are trying to do TDD bottom-up (like most,
> if not all, of the articles and books do), but do design top-down like I
> do.
> 
> Bottom up works well after you already have a rough design in mind and you
> have enough experience to guess where to start at the bottom to realize

(Continue reading)

Steven Gordon | 25 Jan 2012 02:10

Picon

Re: Getting the mindset

The acceptance test could be on the same object as my first unit test, but
an acceptance test is much broader than a unit test, usually involving what
happens during a sequence of operations.  My unit tests on the highest
level object would each have a single assertion about one specific thing
that happens as a result of a single operation in isolation.

On Tue, Jan 24, 2012 at 2:11 PM, mpnalvin <markpaters <at> gmail.com> wrote:

> **
>
>
> Steven,
>
> The method you outlined is almost exactly what I had in mind (in my case,
> derived from the "Growing Object-Oriented Software" book). GOOS calls it
> "outside-in" programming, since you effectively follow the message trail
> from the highest level down to the lowest. The "top-down" nature of the
> approach was a a big factor for me. One thing I'm trying to do is to
> understand the different types of TDD approaches. I'd call yours "top-down,
> depth-first" since you use recursion and a stack :) GOOS, on the other
> hand, uses Mocks, so it's more "top-down, breadth-first." I don't know
> enough to have a strong feeling either way about Mocks, but I'm going to
> try them and see whether I like the results.
>
> One thing that GOOS does that I found significant is that they start with
> an acceptance-level (end-to-end) test. I thought this was an interesting
> approach since they are then able to derive a system more-or-less directly
> from the driving user story. This may be why they call their approach
> "outside-in" rather than just "top-down." When you mentioned that you start
> with the highest-level object, would your initial tests be acceptance

(Continue reading)

Steven Gordon | 25 Jan 2012 02:21

Picon

Re: Getting the mindset

On Tue, Jan 24, 2012 at 2:11 PM, mpnalvin <markpaters <at> gmail.com> wrote:

> **
>
>
> Steven,
>
> The method you outlined is almost exactly what I had in mind (in my case,
> derived from the "Growing Object-Oriented Software" book). GOOS calls it
> "outside-in" programming, since you effectively follow the message trail
> from the highest level down to the lowest. The "top-down" nature of the
> approach was a a big factor for me. One thing I'm trying to do is to
> understand the different types of TDD approaches. I'd call yours "top-down,
> depth-first" since you use recursion and a stack :) GOOS, on the other
> hand, uses Mocks, so it's more "top-down, breadth-first." I don't know
> enough to have a strong feeling either way about Mocks, but I'm going to
> try them and see whether I like the results.
>

I do not mind using mocks, but I generally prefer depth-first to
breadth-first because I expect depth-first to complete something that
actually works end-to-end for some thin slice of functionality faster than
breadth-first.  That provides the opportunity to get quicker feedback on
whether the whole idea is on-target or not.  That feedback then allows me
to learn things I can apply to the rest of the depth-first slices and also
to do a end-to-end refactoring that might simplify the design.  With
breadth-first, my fear is that I would sometimes repeat the same
misthinking about the problem (or the solution) over and over again before
I would discover that I was misthinking.

(Continue reading)

jacek_ratzinger | 25 Jan 2012 14:56

Picon

Re: Getting the mindset

Mocks or Stubs can help with combining outside-in and depth-first.
- sketch first
- executable sketch
- mocked implementation
- more tests
- in depth implementation

The outside in part is contributed by the starting point of your journey. Like for example in Behavior
Driven Development (BDD) you write first a sketch of the functionality you want to implement - BDD uses
examples for the sketch format. Then you make the examples executable - in fact you use the examples as
direct input to your tests (e.g. with frameworks such as Cucumber or Concordion).
Thus, your first test represents an concrete instance (an example) of your user story.

This first test comes from the user perspective. To get quick feedback you implement the test and mock / stub
the details. You go from red to green as soon as possible.

Then you focus on the mocked / stubbed elements and write tests for the next level of implementation. Based
on the next test you code the next level mocking elements of deeper levels. ...

Such a process comes from the user perspective (outside-in) and goes depth-first to complete the implementation.

Greets, Jacek

--- In testdrivendevelopment <at> yahoogroups.com, "mpnalvin" <markpaters <at> ...> wrote:
>
> Steven,
> 
> The method you outlined is almost exactly what I had in mind (in my case, derived from the "Growing
Object-Oriented Software" book). GOOS calls it "outside-in" programming, since you effectively
follow the message trail from the highest level down to the lowest. The "top-down" nature of the approach

(Continue reading)

Ken | 26 Jan 2012 22:24

Picon

Re: Getting the mindset

That explanation sounds v cool to me! 

I think a critical goal should be that, when a functional test fails on a build, then this should mean
something to the product owner - 'why is my feature broken?'

I've been in the situation where failing tests are ignored by devs, architects and product owners alike, as
most of the tests have been made up by devs on a whim, many don't make any sense a few months down the track, and
critical areas are overlooked [a large  company with some v bright minds!?! - in fact, the team had done so
poorly in this regard, management had to introduce an absolute quality bar before check in = a flaky 40
minute end-to-end UI automation test suite had to pass before check-in... and only one dev could check in
at a time => architecture fail!]

Having a functional use case driven specification, which in turn drives a test, is a much better place to be.  
Imagine if 30% of your most critical code is just made up by devs, depending on whether they can be bothered
to think about this or not??  That's the situation in many dev shops. 

I don't think you can push the ATDD / BDD rationale all the way down the stack though - you may have functional
tests on the outside, but inner unit tests belong 100% to the development team, they're a tool for emergent
design and refactoring.  The product owner is entitled to (and must) insist on a minimum level of coverage,
that's all.

Having an architect say 'don't refactor you'll introduce bugs' is the kind of thing BDD helps to avoid, as
the product owner has some visibility of quality throughout.  And you have to exercise some control over
the muppets, because there are more of them than good developers on any team!

Kennos!

--- In testdrivendevelopment <at> yahoogroups.com, "jacek_ratzinger" <ratzinger.jacek <at> ...> wrote:
>
> Mocks or Stubs can help with combining outside-in and depth-first.

(Continue reading)

Jeffrey | 24 Jan 2012 18:13

Re: Getting the mindset

I've really enjoyed the Let's Play TDD video sessions by James Shore.  It might look daunting, since there
are so many posted, but each one is 15 mins or less so it makes it easy to watch a video or two here and there.  The
first 10 videos could probably be skipped without loosing out on too much context (he also created recap
videos that you could start out with).  

What I really liked from the series is the repetition - watching the process in length has really helped me
get into the mindset of the TDD process.  

--- In testdrivendevelopment <at> yahoogroups.com, "mpnalvin" <markpaters <at> ...> wrote:
>
> Hi all! I have several years of experience in traditional development, but I'm trying to adapt to a TDD
approach. The trouble is, I can't get the mindset right. I believe I understand the methodology, and I have
several good books to refer to, but here's what happens.
> I start off thinking "OK, got to write that first test. What should it be?" Then I get a design idea. Then my
brain gets excited. It doesn't want to write the test; it wants to follow the idea. It heads off at speed down
the trail, throwing up design candidates, creating interfaces, throwing in the odd pattern etc. as fast
as I can scribble. I try to say to my brain "Bad brain! You are not allowed to think about this. The design
needs to emerge from the test cases." But honestly, cutting off that flow of potentially fruitful ideas
and forcing myself back to the business of plodding along one test at a time reminds me of Douglas Adam's
description of drinking a pan-galactic gargleblaster. Is this just how it is when you start TDD? Am I
addicted to design? :)
> 
> I have read some TDD books ("Growing Object-Oriented Software" comes to mind) where there does seem to be
some level of design up front and initial tests serve to validate the architecture. I would love to hear
from those of you who have succeeded in adapting to TDD how you find the design emerging. Do you have a
broad-brush solution up front, using TDD to get the low-level details right, or do you go into TDD with
nothing more than an initial user story and no design in mind?
>

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

(Continue reading)

mpnalvin | 24 Jan 2012 22:13

Picon

Re: Getting the mindset

> I've really enjoyed the Let's Play TDD video sessions by James Shore. 
Jeffrey, that's a great suggestion. I'll definitely check those out.

Mark

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    testdrivendevelopment-digest <at> yahoogroups.com 
    testdrivendevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

(Continue reading)

George Dinwiddie | 24 Jan 2012 21:48

Re: Getting the mindset

Hi, Mark,

On 1/23/12 9:25 PM, mpnalvin wrote:
> Hi all! I have several years of experience in traditional
> development, but I'm trying to adapt to a TDD approach. The trouble
> is, I can't get the mindset right. I believe I understand the
> methodology, and I have several good books to refer to, but here's
> what happens.
 >
> I start off thinking "OK, got to write that first test. What should
> it be?" Then I get a design idea. Then my brain gets excited. It
> doesn't want to write the test; it wants to follow the idea.

Right there, write a test that requires the first inkling of that design 
idea.

> It heads
> off at speed down the trail, throwing up design candidates, creating
> interfaces, throwing in the odd pattern etc. as fast as I can
> scribble. I try to say to my brain "Bad brain! You are not allowed to
> think about this. The design needs to emerge from the test cases."

You can't help but think about the design. That's a good thing.

> But honestly, cutting off that flow of potentially fruitful ideas and
> forcing myself back to the business of plodding along one test at a
> time reminds me of Douglas Adam's description of drinking a
> pan-galactic gargleblaster.

Write your tests /while/ you're thinking about design. I suspect that,

(Continue reading)

mpnalvin | 24 Jan 2012 23:58

Picon

Re: Getting the mindset

> When I started TDD, I would have a design in mind and use the tests to 
> force that design into existence. That works OK.
Hmm... your language here is striking. I've always thought of the initial design as the good guy, and code as
the disreputable cousin who uses any excuse to avoid working. But you're right -- the initial design could
be a dictator, forcing the code into contortions. That's helpful for me. Thanks.

> Now, I'm more likely to start with a test that's a statement of the 
> functionality or user story, and use that to drive the API of the 
> implementing class.
Good! It seems like I'm seeing some convergence around this "top-down" type of approach, and that suits me
fine since top-down is how I'm used to working.

Mark

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    testdrivendevelopment-digest <at> yahoogroups.com

(Continue reading)

Esko Luontola | 29 Jan 2012 13:55

Picon

Re: Getting the mindset

mpnalvin wrote on 24.1.2012 4:25:
> I start off thinking "OK, got to write that first test. What should it
> be?" Then I get a design idea. Then my brain gets excited. It doesn't
> want to write the test; it wants to follow the idea.

That's normal in the beginning. When I first tried TDD (it was a small 
utility program, without any external dependencies making things 
harder), I decided that I would do it 100% test-first. It took me about 
two hours, staring at an empty project, to figure out what test to write 
first. After the initial hurdle, it took a couple of days to rewire my 
head, so that writing a test first would feel more-or-less naturual. Of 
course my tests weren't yet very good, occasionally I slipped back to 
old habbits, and it took nearly a year for me to be happy with how I was 
naming my tests (my yardstick was http://dannorth.net/introducing-bdd/).

I've sometimes taught others TDD and I've had good responses about this 
TDD tutorial that I wrote: 
https://github.com/orfjackal/tdd-tetris-tutorial It consists of writing 
a simple application and the first 30 tests have been provided, to get 
the hang of what kind of tests to write, before it's time to write them 
yourself. Based on a poll in the middle of this tutorial, it took my 
students less than 15 minutes to write their first own test - much 
faster than when I got started.

> I try to say to my brain "Bad brain! You are not allowed to think about
> this. The design needs to emerge from the test cases."

The same as you, I'm getting lots of design ideas of how things could be 
implemented. But to try to avoid speculating what *might* be needed 
(http://en.wikipedia.org/wiki/You_ain't_gonna_need_it), I will write

(Continue reading)

MarvinToll.com | 31 Jan 2012 01:43

Re: Getting the mindset

Knowing this is seemingly trivial and pedantic... 

I just hate the word "mindset"... thinking that the Agile mind should never be "set".

Mindframe works better for me.

--- In testdrivendevelopment <at> yahoogroups.com
>
The trouble is, I can't get the mindset right.

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    testdrivendevelopment-digest <at> yahoogroups.com 
    testdrivendevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe <at> yahoogroups.com

(Continue reading)

Ken | 1 Feb 2012 01:00

Picon

Re: Getting the mindset


Nahh - mindframes are too restrictive.  You have the wrong noun?  A set can be extended unless it's closed, so
perhaps we need to emphasise the right mindopenset?

--- In testdrivendevelopment <at> yahoogroups.com, "MarvinToll.com" <MarvinToll <at> ...> wrote:
>
> Knowing this is seemingly trivial and pedantic... 
> 
> I just hate the word "mindset"... thinking that the Agile mind should never be "set".
> 
> Mindframe works better for me.
> 
> --- In testdrivendevelopment <at> yahoogroups.com
> >
> The trouble is, I can't get the mindset right.
>

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

(Continue reading)

MarvinToll.com | 1 Feb 2012 21:52

Re: Getting the mindset

In decision theory and general systems theory, a mindset is a set of assumptions, methods or notations held
by one or more people or groups of people which is so established that it creates a powerful incentive
within these people or groups to continue to adopt or accept prior behaviors, choices, or tools. This
phenomenon of cognitive bias is also sometimes described as mental inertia, "groupthink", or a
"paradigm", and it is often difficult to counteract its effects upon analysis and decision making processes.

http://en.wikipedia.org/wiki/Mindset 

--- In testdrivendevelopment <at> yahoogroups.com, "Ken" <kenmccormack <at> ...> wrote:
> 
> Nahh - mindframes are too restrictive.  You have the wrong noun?  A set can be extended unless it's closed, so
perhaps we need to emphasise the right mindopenset?
> 
> --- In testdrivendevelopment <at> yahoogroups.com, "MarvinToll.com" <MarvinToll <at> > wrote:
> >
> > Knowing this is seemingly trivial and pedantic... 
> > 
> > I just hate the word "mindset"... thinking that the Agile mind should never be "set".
> > 

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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

(Continue reading)

David Burstin | 2 Feb 2012 00:15

Picon

Re: Re: Getting the mindset

http://xkcd.com/386/

On 2 February 2012 07:52, MarvinToll.com <MarvinToll <at> gtcgroup.com> wrote:

> **
>
>
> In decision theory and general systems theory, a mindset is a set of
> assumptions, methods or notations held by one or more people or groups of
> people which is so established that it creates a powerful incentive within
> these people or groups to continue to adopt or accept prior behaviors,
> choices, or tools. This phenomenon of cognitive bias is also sometimes
> described as mental inertia, "groupthink", or a "paradigm", and it is often
> difficult to counteract its effects upon analysis and decision making
> processes.
>
> http://en.wikipedia.org/wiki/Mindset
>
> --- In testdrivendevelopment <at> yahoogroups.com, "Ken" <kenmccormack <at> ...>
> wrote:
> >
> > Nahh - mindframes are too restrictive. You have the wrong noun? A set
> can be extended unless it's closed, so perhaps we need to emphasise the
> right mindopenset?
> >
> > --- In testdrivendevelopment <at> yahoogroups.com, "MarvinToll.com"
> <MarvinToll <at> > wrote:
> > >
> > > Knowing this is seemingly trivial and pedantic...
> > >

(Continue reading)

Return

Return to gmane.comp.programming.test-driven-development.

Project Web Page

Discussion of the eXtreme Programming practice of TestDrivenDevelopment

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane