headers
Doug Swartz | 1 Jan 2004 01:06
Picon

Re[4]: Re: should we work on projects that can't be released after an iteration?


Wednesday, December 31, 2003, 9:38:07 AM, Steve Bate wrote:

>> From: Doug Swartz [mailto:daswartz <at> prodigy.net]
>> > Well, if you could just get down to releasing every iteration, then you
>> > would roll all the practices of release planning into iteration
>> > planning, and be done with it, right?
>>
>> No.
>>
>> We're working on a project to extend an existing system to
>> meet the needs of a large new customer. Even though we can
>> (and do) release the system to the existing customers every
>> iteration, we still need the longer term view provided by
>> release planning to know if we're on target to meet our
>> deliverables two or three months in the future.
>>
>> As Ron noted somewhere else in the thread: Iterations give
>> feedback which helps us optimize locally (hill climbing);
>> Release Planning gives us the longer term view (map reading to
>> see if we're in the right county).

> Hi Doug,

> I think that what Steve and myself and others are saying is
> that sometimes hill climbing is a valid primary strategy
> when the actual business "terrain" is constantly shifting
> and there are /no reliable maps/. This is when agility is
> most needed. Fortunately, most projects don't operate in
> this environment so map following works reasonably well.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Steve Howell | 1 Jan 2004 01:17

Re: best way to identify points of diminishing returns

Doug Swartz wrote:

>Wednesday, December 31, 2003, 2:05:50 PM, Steve Howell wrote:
>
>
>  
>
>>I had a friend who had an interesting theory about software development. 
>>He said that the software developer should always have to do the 
>>customer's job for a while, and then the software developer would simply 
>>use his computer skills to automate away the most odious tasks. That to 
>>me seems like the ultimate lightweight, human-based approach to software 
>>development.
>>    
>>
>
>Have you or your friend tried this? 
>
I haven't really had the opportunity to try it, but I hope to some day.

>I have. In the early 90's
>I worked for a telemarketing company. Every IT person had to
>go through the basic 5 day class for taking phone calls. At 
>the end of training, we each took a half hour of phone calls
>(with supervisors close at hand, just like new telemarketers).
>The ideas and improved software which resulted were well worth
>the time invested (At that time, 1 second saved off the
>average phone call was worth $100,000 per year to the bottom
>line).
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Gilbertson | 1 Jan 2004 01:27
Picon
Favicon

Re: re: XP, unit testing and accepted failures


   Ah yes, the mock object.  That seems to slip out of
my consciousness once in a while (as I said, I'm still
getting used to XP ;-).

   But, your most helpful comment was the confirmation
of my inclination to treat it as a real defect.  "But
how to deal with that?" I thought.  You say, "with
ACCEPTANCE tests."  That sounds very reasonable, and
fits the framework.  However, let me pose a scenario:
I decide to handle a disconnect.  This in turn fails
the actual unit test.  What then?  Basically, my
concern is for those situations where you simply
cannot guarantee success (in a reasonable manner.. I
would be lenient in a situation where memory capacity
is not a concern) -- unit testing seems to take the
approach that you can guarantee success through the
presence of 100% code-coverage testing.  It occurs to
me now, though: unit testing IS for ideal situations,
in some respects (i.e., the network).  However, XP has
not told me (yet) how to deal with failure.

   That was pretty roundabout, but you did reassure me
and give me plenty to think about.  Thank you!

- Sean

--- John Brewer <jbrewer <at> jera.com> wrote:
> >    I'm just getting into XP and unit testing, and
> I like what I see
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ron Jeffries | 1 Jan 2004 01:28
Favicon

Re: Re: should we work on projects that can't be released after an iteration?

On Wednesday, December 31, 2003, at 7:06:25 PM, Doug Swartz wrote:

> The difference
> is that the people programming for the derivatives companies
> were forced to start being agile long before the rest of us. 

I really wonder whether the best strategy in those companies is just to
continually code "the most important thing" like demons.

It might be. Doesn't really sound like fun. I suppose the money is good.

Ron Jeffries
www.XProgramming.com
You don't want to sell me waterfall.
You want to go home and rethink your life.

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 

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/extremeprogramming/

To unsubscribe from this group, send an email to:
 extremeprogramming-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 8 comments |
headers
Sean Gilbertson | 1 Jan 2004 01:37
Picon
Favicon

Re: re: XP and MVC


   I'll definitely check out those books.  I've seen
that collection of books (XP [explained | installed |
* ] ), and have just glanced at them.  I've gone
through the first two units of the Martin book (about
150 pages) in a few days, and it got me fired about
about TDD, XP, and the agile practices.  I was
previously into the book I got while in school,
"Applying UML and Patterns," but that book, while
valuable, is stuffy and certainly process-bound.  In
fact, I found the UML reference (an appendix) in the
Martin book to be more than adequate!

   The Martin book is pretty good, but you're right:
at least one of the examples has been a
head-scratcher.  I'm at the first big case study now,
and I'll see where he's going with that.

   I had the same reaction you do: that XP should lead
to MVC.  I'm considerably open-minded, but very
skeptical as well.

   XP initially turned me off, despite its many
benefits, because it's a common tenet of XP to
pair-program.  However, my habits lean me very much
towards XP ("let's code right now"), so here I am.  I
certainly appreciate good design, and I am totally OO,
so I'm hoping this is the "killer app" it might be. 
Additionally, I do believe I could gain things by
pair-programming, but I think I'll be alright without
(Continue reading)

Permalink | Reply | 8 comments |
headers
John Brewer | 1 Jan 2004 01:39
Favicon
Gravatar

Re: re: XP, unit testing and accepted failures

>However, let me pose a scenario:
>I decide to handle a disconnect.  This in turn fails
>the actual unit test.  What then?

Could you elaborate on this scenario?  It's not quite clear to me. 
What do you mean by "I decide to handle a disconnect"?  And why would 
doing that fail a unit test?
-- 

John Brewer
Jera Design

Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html

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 

Yahoo! Groups Links

To visit your group on the web, go to:
 http://groups.yahoo.com/group/extremeprogramming/

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

Your use of Yahoo! Groups is subject to:
 http://docs.yahoo.com/info/terms/
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sean Gilbertson | 1 Jan 2004 01:44
Picon
Favicon

Re: re: XP and MVC


   I'm going to take this weekend (and perhaps part of
my day tomorrow) applying some XP principles to a test
(and eventually production) application.  I'm trying
to hammer out my conerns, and this list has already
paid off wonderfully.

   The comment you made that I find the most
interesting is: "The thing to avoid like the plague is
the temptation to test the application itself through
the user interface."  This could be considered an
obvious piece of advice, but in fact, I've done it
almost exclusively in my previous projects!  XP has
already made me a convert-in-practice, rather than
just -in-writing.

   I'm going to visit the sites you recommended, and
meditate on the responses I've gotten, while reading
this book, and checking out some others.

Thank you for your time and comments!
   Sean

--- yahoogroups <at> jhrothjr.com wrote:
> From: "smogallstar"
>
<smogallstar.at.yahoo.com <at> yahoogroups.at.jhrothjr.com>
> Sent: Wednesday, December 31, 2003 6:05 PM
> Subject: [XP] re: XP and MVC
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
yahoogroups | 1 Jan 2004 01:51

Re: re: XP and MVC

From: "Sean Gilbertson"
<smogallstar.at.yahoo.com <at> yahoogroups.at.jhrothjr.com>
Sent: Wednesday, December 31, 2003 7:37 PM
Subject: Re: [XP] re: XP and MVC

>    XP initially turned me off, despite its many
> benefits, because it's a common tenet of XP to
> pair-program.

I'm not entirely sure why pair programming seems
to turn so many people off. Doing it effectively
is a skill that can be learned, although it seems like
it's best learned subliminally by pairing with a
good trainer.

> However, my habits lean me very much
> towards XP ("let's code right now"), so here I am.  I
> certainly appreciate good design, and I am totally OO,
> so I'm hoping this is the "killer app" it might be.
> Additionally, I do believe I could gain things by
> pair-programming, but I think I'll be alright without
> it (and I certainly hope so: most of my projects are
> solo, and I'm the only programmer at my company!).

You can't, of course, pair when there's no one else
on the project! On a one developer project, some of
the advantages of pairing (information transfer, for
example) simply don't apply. However, there are other
functions such as enforcing coding standards, providing
error checking and putting two different viewpoints
(Continue reading)

Permalink | Reply | 7 comments |
headers
Sean Gilbertson | 1 Jan 2004 02:16
Picon
Favicon

Re: re: XP, unit testing and accepted failures


   By handle, for example: I surround a "connect( )"
in a try block, and connect throws a
"CouldNotConnectException" (or something.  In this
scenario, the function fails  and either propagates
the exception or returns something unexpected or
unwanted.  If you wrote a unit test that ensured that
something was received off the socket, that would fail
the unit test.

- Sean

--- John Brewer <jbrewer <at> jera.com> wrote:
> >However, let me pose a scenario:
> >I decide to handle a disconnect.  This in turn
> fails
> >the actual unit test.  What then?
> 
> Could you elaborate on this scenario?  It's not
> quite clear to me. 
> What do you mean by "I decide to handle a
> disconnect"?  And why would 
> doing that fail a unit test?
> -- 
> 
> John Brewer
> Jera Design
> 
> Extreme Programming FAQ:
> http://www.jera.com/techinfo/xpfaq.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
yahoogroups | 1 Jan 2004 03:11

Re: re: XP, unit testing and accepted failures

From: "Sean Gilbertson"
<smogallstar.at.yahoo.com <at> yahoogroups.at.jhrothjr.com>
Sent: Wednesday, December 31, 2003 8:16 PM
Subject: Re: [XP] re: XP, unit testing and accepted failures

>    By handle, for example: I surround a "connect( )"
> in a try block, and connect throws a
> "CouldNotConnectException" (or something.  In this
> scenario, the function fails  and either propagates
> the exception or returns something unexpected or
> unwanted.  If you wrote a unit test that ensured that
> something was received off the socket, that would fail
> the unit test.

> - Sean

I see what you're saying. You're trying to test
exception handling. The easiest way to do this
is to mock it out so that you don't call connect()
directly. You have your own proxy for the
library calls. Then you can set up the mock to throw
an exception on the test for whether the exception
handler works, and to simulate a connection on
the tests where you want to test that function.

The last time I had a network project, I did that
and it cut my test time way down.

Where this gets messy is, of course, the question
of whether the mocks are actually modeling the
(Continue reading)

Permalink | Reply | 1 comment |

Gmane