headers
Phlip | 1 Jul 2007 01:01
Picon
Gravatar

Re: Programming Languages and XP (was Re: [OT] Re: Extreme Testing!)

J. B. Rainsberger wrote:

>> I would suggest TDD and Design Improvement, possibly simple design. The
>> others are team practices that are not coupled to the language.
>
> True. Consider COBOL: until very recently, no-one publicly did any work
> in test-driving COBOL code. Can you imagine doing XP without
> test-driving the code? I'm pretty sure there's another thread about that
> here. I couldn't imagine it.

I can imagine designing COBOL using IPO diagrams - Input Processing Output.

I remember staring at those things and thinking there had to be a missing 
abstraction there!

--

-- 
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax 

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com
Permalink | Reply | 0 comments |
headers
Steven Gordon | 1 Jul 2007 01:23
Picon

Re: New to group with quick question.

Ken,

Does your lack of response to my first email indicate that you do not yet
have a first story to deliver?

If not, start by working with your customers to agree on the first few small
story that you can deliver in a short period of time like two weeks.  Then,
focus on doing the simplest thing possible to deliver each small story.

If the last 2 month's code did not deliver those stories (or any specific
stories), then the last 2 months work was an exploratory spike.  Keep the
knowledge gained, but throw away the code.

Steve

On 6/30/07, Steven Gordon <sgordonphd <at> gmail.com> wrote:
>
> Ken,
>
> Do any of these several people waiting for this act as a customer to you?
>
> What was the highest priority story?  Is that story finished to the
> statisfaction of the your customers?
>
> If so, what about the next highest priority story?  On the other hand, if
> the highest priority story is not completed after 2 months, it does not
> sound like you are doing XP.
>
> Steve
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 1 Jul 2007 01:50
Picon
Gravatar

Re: Programming Languages and XP (was Re: [OT] Re: Extreme Testing!)

>> Out of the following, which practices are really affected by the
>> programming language:
>
> OK, just for fun ...

Under the whole list, put "a language that makes Domain Specific Languages" 
easier to generate - even serendipitous.

In terms of "Ubiquitous Language" and "System Metaphor", we are not just 
talking about individual words in the code matching words in the Onsite 
Customer's daily jargon.

We are talking about _entire_statements_ of code appearing as English 
sentences containing that jargon.

Didn't y'all have that with Smalltalk?

--

-- 
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax 

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com
Permalink | Reply | 0 comments |
headers
Amir Kolsky | 1 Jul 2007 02:28
Picon
Favicon

RE: Agility without testability

> I first discovered JUnit when I wanted to answer the question, "How can
> I ship code to my testing department without them finding a bunch of
> bugs I could have found myself?" Instead of answering that question,
> JUnit and test-first programming helped me avoid defects in the first
> place. It does this by encouraging me to think clearly about what code I
> need to write next, rather than just writing it and fixing it later.
> 
> I continue to write automated tests for the safety net: the better my
> tests, the more confidently I can change my code. This takes pressure
> off me to get it right the first time, so I'm more willing to experiment
> and better able to cope with change-from-outside.

Hi Joe,
Everything you're saying is correct. I'm trying to go deeper and understand
why one would want the things that TDD enables, specifically the automation
part.

When we want to determine is an XP (or any other) practice is applicable in
some domain we need to understand the forces at play that made this practice
an effective practice. Then we need to see if these forces are at play at
that other domain. 

In this case we deal with the Automated Testing practice of XP. Is it
relevant for the domain that Bill is in? So, I'm trying to understand
initially what Automated Testing is for him, and then together to see if it
is relevant for his scenario.

Amir

To Post a message, send it to:   extremeprogramming <at> eGroups.com
(Continue reading)

Permalink | Reply | 2 comments |
headers
Amir Kolsky | 1 Jul 2007 02:19
Picon
Favicon

RE: Agility without testability

> > Why do we do automatic tests in XP? What does it buy us?
> It supports continuous integration and allows rapid releases.
> 
> It affords trust for shared ownership.
> 
> It distributes and underpins tacit domain knowledge.
> 
> It helps insure against rollback of shipped features.

OK, so lets start with the first two..

WHY do we want continuous integration and rapid releases?
WHY do we want shared ownership?

Amir Kolsky
Net Objectives
Lean, Agile, TDD 

P.S., This is a serious response. The Automated Testing practice in XP is
good because it if you do it you win some things. I am trying to find out,
with you, what these things are and see whether they are applicable to your
situation.

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com
Permalink | Reply | 3 comments |
headers
J. B. Rainsberger | 1 Jul 2007 02:51
Picon

Re: Agility without testability

Amir Kolsky wrote:

> Everything you're saying is correct. I'm trying to go deeper and understand
> why one would want the things that TDD enables, specifically the automation
> part.

Got it. I did it because my job sucked when I shipping defects to the 
testing team, and it sucked less when I stopped doing that. I got to go 
home at 5 PM, I got to go on vacation, I got to have a life.

> When we want to determine is an XP (or any other) practice is applicable in
> some domain we need to understand the forces at play that made this practice
> an effective practice. Then we need to see if these forces are at play at
> that other domain.
> 
> In this case we deal with the Automated Testing practice of XP. Is it
> relevant for the domain that Bill is in? So, I'm trying to understand
> initially what Automated Testing is for him, and then together to see if it
> is relevant for his scenario.

Then I'll let Bill respond from hereon in.
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Gordon | 1 Jul 2007 03:41
Picon

Re: Agility without testability

Let's cut to the chase:

Automated testing provides consistent, repeatable, objective, fast feedback
so that we can make reliably steady progress towards our goals.  If human
feedback alone was sufficient, pair programming would allow us to make
steady progress towards our goals reliably enough.  Without automated
testing, we would not be doing XP.

This kind of feedback would be very useful for working in any domain, but it
is impractical in most domains, so I just do not see how digging into why it
is useful buys us very much.

In porting XP outside of software development, we must create or find an
analog to automated testing, or develop or choose a different approach.

Many domains have found this need and developed simulation environments that
facilitate defining acceptance criteria, creating solutions, and verifying
how solutions perform against those criteria.  Of course, the work still has
to be deployed from the simulation environment and tested in the real
world.  Whenever something worked in the test environment, but not in the
real world, then there is a bug in the simulation environment that should be
worked around or fixed (hopefully, in the XP style of creating a failing
test that represents the bug, and then making the test pass).

If Bill's target domain does not have suitable simulation environments, then
the choice is between building a suitable simulation environment first,
stumbling around in the domain trying doing XP-- without automated tests, or
looking at different approaches.

Am I making the issue too simple?
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Roth | 1 Jul 2007 03:55
Picon

Re: Agility without testability


----- Original Message ----- 
From: "Amir Kolsky" <kolsky <at> actcom.net.il>
To: <extremeprogramming <at> yahoogroups.com>
Sent: Saturday, June 30, 2007 6:28 PM
Subject: RE: [XP] Agility without testability

>
> Hi Joe,
> Everything you're saying is correct. I'm trying to go deeper and 
> understand
> why one would want the things that TDD enables, specifically the 
> automation
> part.
>
> When we want to determine is an XP (or any other) practice is applicable 
> in
> some domain we need to understand the forces at play that made this 
> practice
> an effective practice. Then we need to see if these forces are at play at
> that other domain.
>
> In this case we deal with the Automated Testing practice of XP. Is it
> relevant for the domain that Bill is in? So, I'm trying to understand
> initially what Automated Testing is for him, and then together to see if 
> it
> is relevant for his scenario.

Let me jump in here. I think there's a bit of a misconception.
TDD is a design technique; you can't do it without building
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 1 Jul 2007 04:51
Favicon

Re: Agility without testability

Hello, Amir.  On Saturday, June 30, 2007, at 8:19:45 PM, you wrote:

> WHY do we want continuous integration and rapid releases?

Feedback?

> WHY do we want shared ownership?

Feedback, rapid learning, more efficient deployment of people?

Ron Jeffries
www.XProgramming.com
If you don't push something beyond its boundary of usefulness
how do you find where that boundary is?  -- Martin Fowler

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com
Permalink | Reply | 1 comment |
headers
John Roth | 1 Jul 2007 05:11
Picon

Re: Agility without testability

From: "Ron Jeffries" <ronjeffries <at> XProgramming.com>
To: <extremeprogramming <at> yahoogroups.com>
Sent: Saturday, June 30, 2007 8:51 PM
Subject: Re: [XP] Agility without testability

> Hello, Amir.  On Saturday, June 30, 2007, at 8:19:45 PM, you wrote:
> 
>> WHY do we want continuous integration and rapid releases?

Also stability for continuous integration: the amount of trouble
you have integrating seems to be super-linear in the length of
time and the amount of code that needs to be integrated.

Frequent releases improves ROI - you start getting
the return for the investment faster.

John Roth

> 
> Feedback?

> Ron Jeffries
> www.XProgramming.com
> If you don't push something beyond its boundary of usefulness
> how do you find where that boundary is?  -- Martin Fowler
> 
>

To Post a message, send it to:   extremeprogramming <at> eGroups.com
(Continue reading)

Permalink | Reply | 0 comments |

Gmane