Next meeting: 7pm Monday 13th May 2002.
All are welcome, especially those thinking of taking up XP.
Location: Swan Tavern, Golbourne Rd, Winwick, Warrington, Cheshire WA2 8LF,
Tel: 0870 7001562. Its close to the M6 / M62 intersection
(http://search.yell.com/search/
ShowMap?scale=50000&companyName=Swan&nat_id=1156331&referer=search&replayURL
=%2Fsearch%2FDoSearch%3Fscreen%3DVAL%26state%3DAMB%26companyName%3DSwan%26sc
rambleSeed%3D8142%26businessType%3DPUBLIC%2BHOUSES%26location%3DWINWICK%26br
oaderLocation%3DWARRINGTON%257CCHESHIRE%257CNORTH%2BWEST%2BENGLAND%257CENGLA
ND%257CUNITED%2BKINGDOM%26&bt_term=PUBLIC+HOUSES&businessType=PUBLIC+HOUSES&
location=WINWICK&panY=0&panX=0)

Please let me know if you would like to come(simonmonk@...).
Would anyone care to volunteer a theme for the meeting to focus the
discussion a bit?

The purpose of this group is to act as a forum both for people practicing Xp
and those thinking of starting Xp to exchange ideas informally. The group is
not sponsored by any organisations and will remain independent.  The format
of our meeting is very relaxed, with no fixed agenda. The emphasis is on
exchanging experiences and picking up tips. We have a range of people
including practitioners, academics, and even those still unsure.

Simon Monk.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Message: 10
     Date: Wed, 1 May 2002 09:34:44 +0100
     From: "Simon Monk" <simonmonk@...>
Subject: An: North of England XP User Group Meeting

>Next meeting: 7pm Monday 13th May 2002.
>All are welcome, especially those thinking of taking up XP.
>Location: Swan Tavern, Golbourne Rd, Winwick, Warrington, Cheshire WA2 8LF,
>Tel: 0870 7001562. Its close to the M6 / M62 intersection
>(http://search.yell.com/search/
>ShowMap?scale=50000&companyName=Swan&nat_id=1156331&referer=search&replayURL
>=%2Fsearch%2FDoSearch%3Fscreen%3DVAL%26state%3DAMB%26companyName%3DSwan%26sc
>rambleSeed%3D8142%26businessType%3DPUBLIC%2BHOUSES%26location%3DWINWICK%26br
>oaderLocation%3DWARRINGTON%257CCHESHIRE%257CNORTH%2BWEST%2BENGLAND%257CENGLA
>ND%257CUNITED%2BKINGDOM%26&bt_term=PUBLIC+HOUSES&businessType=PUBLIC+HOUSES&
>location=WINWICK&panY=0&panX=0)

Or:

http://makeashorterlink.com/?G13A259C

Cheers,
--Carl
--

Cool.

I will try really hard to make it this time.

Phil


********************************************************************************\
******************
The views expressed in this E-mail are those of the author and not necessarily
those of Knowledge Management Software.
If you are not the intended recipient or the person responsible for delivering
to the intended recipient, please be advised that you have received this E-mail
in error and that any use is strictly prohibited.

If you have received this E-mail in error, please notify us by forwarding this
E-mail to the following address:

mailadmin@...
********************************************************************************\
******************

Jim writes:

>Our official process was to identify any technical risk as early as possible
>and do a minimal proof of concept.  If the PoC was successful, we might
>clean up the code and integrate it, or just record the outcome for later.

My own preference, and I'm sorry I can't remember whether I saw this
somewhere or came up with it myself, is to call this a _Test_ of
Concept.  "Proof" to me strongly suggests that you already know the
outcome - far better to undertake such things open-minded, seems to
me.

FWIW,
--Carl
--

If the language is one that is well-known, there is probably a test suite
already created for it. If not, I would start with a grammar and begin
generating the tests that start with small, simple statements, and
non-statements to make sure that it doesn't compile what it shouldn't. Then
I'd continue to build up my test suite as I increased the capability and
uncovered any defects. I used this technique several years ago when I did
the Sun 386i compilers and it had terrific quality.

As for using a parser generator, decide if you need one. I think using one
with C++ was problematical because the C++ grammar is not LR(1). I happen to
prefer writing recursive-descent parsers because I have more control over
them and, I'm sure the XP folks would like this, the code is much more
understandable.

My $.02.

	 --Gary

-----Original Message-----
From: kevinbsmith [mailto:kevinxp@...]
Sent: Tuesday, April 30, 2002 10:42 PM
To: extremeprogramming@yahoogroups.com
Subject: [XP] How to TFD a compiler?


Hypothetically, let's imagine that I plan to write a pseudo
compiler that would take a script language file as input
(perhaps Ruby), and would output "something else" (perhaps
C code, or some kind of bytecode).

As my own Customer, I *know* I want a full langauge, which
would lead me towards using an existing YACC-like tool. But
that is not where I would start if I take a purely TestFirst
approach, one story at a time.

If you were about to start this project, would you:
1. Start right off with something like YACC?
2. Start with a single test, and the simplest possible code
that could pass that test, essentially rolling your own
lexer and parser, and stick with it until it became painful
(and perhaps, maybe, possibly, it never would)?
3. Start rolling your own, but "fairly soon" plan to switch
over to a more powerful and robust solution like YACC?

Kevin



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.com

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

On Wed, 2002-05-01 at 07:13, cmanaster@... wrote:
> Jim writes:
>
> >Our official process was to identify any technical risk as early as possible
> >and do a minimal proof of concept.  If the PoC was successful, we might
> >clean up the code and integrate it, or just record the outcome for later.
>
> My own preference, and I'm sorry I can't remember whether I saw this
> somewhere or came up with it myself, is to call this a _Test_ of
> Concept.  "Proof" to me strongly suggests that you already know the
> outcome - far better to undertake such things open-minded, seems to
> me.

Hmmm... I've alwasy heard/used "Proof".  The way I see it you have an
idea and you want to prove or disprove it's validity.

I haven't used "PoC" in the context of XP though (that was from my
pre-XP days.. my programming equivalent of the dark ages).  The way I
used PoCs is much like I use spikes now.  Very quickly try out an idea
to get a handle on whether it will work and how much it will "cost".

Dave
--
Dave Astels (dastels@...)
   Coauthor of "A Practical Guide to XP"
   Presenter at XP2002 (www.xp2002.org) of:
     "XP For One" tutorial
     "Refactoring with UML" paper
CEO & Master Software Craftsman, Saorsa Development Inc.
www.saorsa.com
"An Agile Software Studio"

Hi Glen,

> >I meant "special case", and I think I'm being sincere and honest
> >here, in the sense that the software you are interested in building
> >isn't the same kind of software that most of us here are interested
> >in building. I could be missing something.
>
> Well this is interesting. Could I conjecture that Agile development and
> therefore XP is NOT applicable to ERP system integration projects?

I'm not sure that XP/Agile is inapplicable in any domain. I do think that
XP/Agile is inappropriate in a lot of situations though, because of the
people and politics in an organisation. I would suggest that, given the
usual Dilbertesque nature of the companies that typically do EAI and ERP
that XP/Agile wouldn't be a good fit (note: I'm not saying that all
companies that by SAP are run by PHBs - just most of them).

> >I expect that a firm with 10K users worldwide which has standardized
> >on SAP could get to regret it.
>
> Amy suggestion as to why this would be the case?

Lack of flexibility. Inability to meet the industry best practice processes
that SAP to some extent dictates. Humanity. Error. Inability for humans to
act like a computer. Lack of understanding of the system. Inability to
comprehend the system. Lack of foresight when implementing the system.

And I am speaking from recent experience.

> The principles and practices espoused in the Agile Alliance Manifesto are
> desperately needed in the ERP domain, just as (and maybe even more than)
> they are in other domains.

Needed, I can understand. Needed more?

Cheers,

Bryan

I'm a big believer in hands-on fun. Much like the "Test-First Challenge" of
a couple months back, I thought I'd create one for refactoring. This is
based on a chapter of the "Refactoring Workbook" that I'm writing.

This and future parts of the challenge will be at
   http://www.xp123.com/rwb/ch15-Example/index.htm

Like before, I'd love to hear from you and see what you've done.
                (William.Wake @ acm.org)

Thanks!
--
   Bill Wake   William.Wake@...   www.xp123.com

=======================================

Chapter 15: A Recursive Example, Part 1


We'll work through an example involving refactoring, test-driven design, and
recursion.

Suppose we've decided to develop a system to play games in the tic-tac-toe
family: squares occupied by different markers. In tic-tac-toe, you have a
3x3 grid, and try to get three in a row. In Connect Four (trademark Hasbro),
you have a rectangular grid, and try to get four in a row, but columns have
to be filled from bottom to top. We'll start with a simplified version of
tic-tac-toe, and work our way up to the general case.

Here are some tests and the first version of the code:

import junit.framework.*;
public class GameTest extends TestCase {
        public GameTest(String s) {super(s);}

        public void testDefaultMove() {
               Game game = new Game("XOXOX-OXO");
               assertEquals(5, game.move('X'));

               game = new Game("XOXOXOOX-");
               assertEquals(8, game.move('O'));

               game = new Game("---------");
               assertEquals(0, game.move('X'));

               game = new Game("XXXXXXXXX");
               assertEquals(-1, game.move('X'));
        }

        public void testFindWinningMove() {
               Game game = new Game("XO-XX-OOX");
               assertEquals(5, game.move('X'));
        }

        public void testWinConditions() {
               Game game = new Game("---XXX---");
               assertEquals('X', game.winner());
        }
}

public class Game {
        public StringBuffer board;

        public Game(String s) {board = new StringBuffer(s);}

        public Game(StringBuffer s, int position, char player) {
               board = new StringBuffer();
               board.append(s);
               board.setCharAt(position, player);
        }

        public int move(char player) {
               for (int i = 0; i < 9; i++) {
                      if (board.charAt(i) == '-') {
                            Game game = play(i, player);
                            if (game.winner() == player)
                                   return i;
                      }
               }

               for (int i = 0; i < 9; i++) {
                      if (board.charAt(i) == '-')
                            return i;
               }
               return -1;
        }

        public Game play(int i, char player) {
               return new Game(this.board, i, player);
        }

        public char winner() {
               if (board.charAt(0) != '-'
              && board.charAt(0) == board.charAt(1)
              && board.charAt(1) == board.charAt(2))
                      return board.charAt(0);

               if (board.charAt(3) != '-'
              && board.charAt(3) == board.charAt(4)
              && board.charAt(4) == board.charAt(5))
                      return board.charAt(3);

               if (board.charAt(6) != '-'
              && board.charAt(6) == board.charAt(7)
              && board.charAt(7) == board.charAt(8))
                      return board.charAt(6);

               return '-';
        }
}


Notice that the winner() routine is simplified: you win by getting three in
a row horizontally. Notice also that the heuristics for what to play are
primitive: win if you can, play anything otherwise. We'll migrate toward
something capable of more sophisticated strategies.

Exercise:
Go through this code and identify smells.

Exercise:
It's not always easy to know what to do with code. Let's fix some of the
easy things first. Fix them one at a time.
* The name move() isn't descriptive enough. Change it to bestMoveFor().
* The variable i doesn't explain much either. Change it to move.
* The value -1 is a flag value; create a constant NoMove to represent it.
* The winner() function has a lot of duplication. Eliminate the duplication.
* The check for a board character being a '-' is really a check that the
square is unoccupied. Extract a method to do this, and name it
appropriately.


We have two "for" loops: one to find a winning move, the other to find a
default move. One way to handle this would be to extract each one into a
method. As we add more strategies, we could see each strategy getting its
own method. An alternative would be to merge the two loops and handle things
more in one pass through the possible moves. We'll take the latter approach.

Exercise:
We haven't talked about the "Fuse Loops" refactoring. Find a way to merge
these two loops. Do so in small steps, in such a way that you maintain
safety as you do it. When is it safe to merge two loops?


One step along the way might be to assign a value to a temporary variable
rather than return it right away. You might have made the second loop look
like this:
     defaultMove = NoMove;
     for (int i = 0; i < 9; i++) {
        if (board[i] == '-')
              if (defaultMove == NoMove)
                      defaultMove = i;
     }


That was the safe approach, used because we did not want our refactoring to
change behavior. To be equivalent to the original, we need the guard clause
to make sure we haven't assigned a defaultMove yet. But let's put on a
development hat: we don't really care which default move we make, so we
could delete the "defaultMove==NoMove" test. It's not necessary to stop when
we find a viable move. (That is, there's no harm in trying each possible
move provided we prefer wins to defaults.) So you can delete the "break"
tests that exit early. Run the tests again and be sure you haven't changed
anything important.

Now we have a single loop, but the condition to decide what to return is
still a little complicated:
     if (winningMove != NoMove)
        return winningMove;
     if (defaultMove != NoMove)
        return defaultMove;
     return NoMove;


Exercise:
What refactorings would you tackle next?

Hi Brian,

> > I always code to the mainline. If this program has to be bulletproof,
> > i.e. deal with bad input, I probably want a story for that.
>
> Ron, do you tell your customers this up front?  I could see a customer
> expecting this kind of error checking "for free".  Then he would never
> specifically ask for it.

Never is a long time. I'd be willing to bet that if a customer wanted this
sort of bulletproofing, and forgot to mention it, he'd notice at the start
of week 4 when he's examining the first release of the system that it
hasn't got it.

This would provide feedback to him that he hasn't fully communicated his
intent, and so a conversation will ensue in which he would fully specify
his requirements - including bulletproofing. From that point on the
developers can factor the extra time for this style of code, and the
customer can choose to pay for it or not.

Cheers,

Bryan

Bryan,

All good points except I'm a bit confused on the last...more below.

>-----Original Message-----
>From: Bryan responding to...
>Hi Glen,
>
>> >I meant "special case", and I think I'm being sincere and honest
>> >here, in the sense that the software you are interested in building
>> >isn't the same kind of software that most of us here are interested
>> >in building. I could be missing something.
>>
>> Well this is interesting. Could I conjecture that Agile development and
>> therefore XP is NOT applicable to ERP system integration projects?
>
>I'm not sure that XP/Agile is inapplicable in any domain.

I would agree and disagree. The "agile" concepts are much broader IME than
the XP practices. So applying Agile - as defined in Scott Amblers AM
practices and transformed into ERP terminology is being put to the test as
we speak.

>I do think that XP/Agile is inappropriate in a lot of situations though,
because of the
>people and politics in an organization. I would suggest that, given the
>usual Dilbertesque nature of the companies that typically do EAI and ERP
>that XP/Agile wouldn't be a good fit (note: I'm not saying that all
>companies that by SAP are run by PHBs - just most of them).

Yes, picking the audience is important, but even in the presence of "problem
clients" the principles can be used to advantage.

>> >I expect that a firm with 10K users worldwide which has standardized
>> >on SAP could get to regret it.
>>
>> Amy suggestion as to why this would be the case?
>
>Lack of flexibility. Inability to meet the industry best practice processes
>that SAP to some extent dictates. Humanity. Error. Inability for humans to
>act like a computer. Lack of understanding of the system. Inability to
>comprehend the system. Lack of foresight when implementing the system.
>
>And I am speaking from recent experience.
>
>> The principles and practices espoused in the Agile Alliance Manifesto are
>> desperately needed in the ERP domain, just as (and maybe even more than)
>> they are in other domains.
>
>Needed, I can understand. Needed more?

More, yes because of the gaps in the domain. A small team of experience
developers working with their customer could probably use almost any method
or even no formal method and have success. The ERP domain is fraught with
systemic problems, some of which can be addressed by agile.

>Cheers,
>
>Bryan

Glen

Quoting extremeprogramming@yahoogroups.com:

>    From: Ron Jeffries <ronjeffries@...>
>
> Around Monday, April 29, 2002, 1:42:54 PM, J. B. Rainsberger wrote:
>
> > Team          W   L   Pct   GBL
> > Toronto       6   2  .750    --
> > Baltimore     5   3  .625     1
> > Boston        5   4  .556     1 1/2
> > New York      3   5  .375     3
> > Tampa Bay     1   6  .143     4 1/2
>
> Here's the next installment. It's a long one, not least because it has
> a complete listing.
>
> ==========================================
>
> Well, OK, what shall I do now? There aren't really any interesting
> problems left that I can see.

OK, this is an interesting statement. Let's review what you have so far -- even
by the end of this session:

* Games back is computed, although the sign is wrong. Trailers are currently
negative-n games back, rather than n games back.
* Sort by winning percentage works.
* Leader is correctly identified.
* Can process a file that's not quite the format required.

What is not done:

* Categorizing teams into divisions and leagues.
* Reporting on the leaders within each division.
* Correct formatting.
* Process the original input format requested.

From your comment, what's not done is not "interesting" to you. I think if you
can describe why, that would be the central thing to learn from you in this
exercise. What makes the things you haven't done yet "uninteresting" compared
to the things you've already done which are "interesting". Thanks!

> That looks about right. Now let's see about getting GBL. That'll be
> tricky, I will have to pass in the leader team. (I don't know which
> team is leader ... never tested that feature. I guess I'm about to.)

Why not a separate unit test for this feature?

PS: I apologize for not providing better AT data. I'm still learning to be a
customer, too. :)

J. B. (Joe) Rainsberger
President, Diaspar Software Services
http://www.diasparsoftware.com
Let's write software that people understand.

Hi Carl,

> My own preference, and I'm sorry I can't remember whether I saw this
> somewhere or came up with it myself, is to call this a _Test_ of
> Concept.  "Proof" to me strongly suggests that you already know the
> outcome - far better to undertake such things open-minded, seems to
> me.

See definitions 4 and 3a at <http://www.dictionary.com/search?q=proof>.

Dale

Ron,

> How do you know that every busy signal you ever got wasn't a wrong
> number?

Ah... the perennial problem. Can't write a test that proves something
never happens. Maybe Laurent needs to update his software:
	 ASSERT( WhatImThinking == WhatIDialed );

Charlie Poole
cpoole@...

Hi Ron,

> > By "architectural decision," I mean any decision that
> > significantly affects the system's quality attributes.
>
> So "extensive testing" is an architectural decision, as is "do code
> reviews"?

That fits what I said, but not what I was thinking.  I left out an important
word -- design -- that I had included in my earlier definitions.  So I'll add it
back in:  By "architectural decision," I mean any design decision that
significantly affects the system's quality attributes.

By "design decision," I mean a decision that either (1) selects elements of
technology for inclusion in the system, or (2) defines how those elements
interact to carry out the system's responsibilities.

> > Now, you may not agree with my definitions for "quality
> > requirements" or "architectural decision."  But can you see how
> > my definitions lead to the implication you asked me to explain?
>
> Yes. I don't think the definition corresponds to what people
> usually think of as "architectural" decisions, see the examples
> above. But I see how the logic works. I think I'd call them
> "quality decisions" or something, but what do I know?

Given my revised definition, what do you think now?  Can you think of any
architectural decisions that don't fit my definition?  Can you think
non-architectural decisions that do fit it?

Dale

Glen,

> So thinking too much or thinking too little is the "real"
> problem. It's all
> about "thinking right," and that's much harder to do than too much or too
> little.

When you're lost in the woods, and you know that the fire road where your
car is parked is somewhere to the north, you head north of course. But you
*don't* try to head for your car. If you did that, you'd most likely
reach the road somewhere, but might not know which way to walk. So you
head a little east (or west, if that's more convenient) of north. Now
when you reach the road, you can confidently turn left (or right) and
expect to shortly find your car.

Similarly, since it's hard to do just the right amount of architecture up
front, we need to aim either high or low. Aiming low is more convenient
for two reasons. First, we avoid doing work that may not be needed. Second,
and perhaps more important, teams seem to have more trouble dropping those
practices which are not pulling their weight than they do adding new ones.

Based on your comments in other threads, I suspect this is what you're
doing. You seem to be a bit heavy on architecture as compared to many
other folks here, but it sounds as if you're tons lighter than other
people doing similar things.

Charlie Poole
cpoole@...

Kevin,

> Hypothetically, let's imagine that I plan to write a pseudo
> compiler that would take a script language file as input
> (perhaps Ruby), and would output "something else" (perhaps
> C code, or some kind of bytecode).

If this becomes, non-hypothetical, please let us know what
you do and how it works out.

> As my own Customer, I *know* I want a full langauge, which
> would lead me towards using an existing YACC-like tool. But
> that is not where I would start if I take a purely TestFirst
> approach, one story at a time.

I'm trying to make this decision right now.

> If you were about to start this project, would you:
> 1. Start right off with something like YACC?
> 2. Start with a single test, and the simplest possible code
> that could pass that test, essentially rolling your own
> lexer and parser, and stick with it until it became painful
> (and perhaps, maybe, possibly, it never would)?
> 3. Start rolling your own, but "fairly soon" plan to switch
> over to a more powerful and robust solution like YACC?

Here's where I'm tending in my own thinking - no guarantee
that I won't change my mind though.

I'm not convinced that YACC is necessarily more powerful and
robust than what I might do. If I use YACC, I'm still coding
when I write new productions and regenerate the parser. Using
YACC means that I need to test my produtions and since I'm
not really sure how to do that, I may not do it as well as
if I were testing code in C# or C++.

So I'm leaning toward #3, with the difference that I won't
go with YACC unless I have a need to do it. If I discover
some easy way to do my testing and use YACC, then I may
change my mind.

I'll do a minimal up front design: parser talks to lexer
and generates tree structure. Since my language has an
eval feature, the tree nodes need to know how to either
generate code or directly evealuate themselves. A higher
level component will deal with reading files and passing
them to the parser. That's it... subject to change as
the application emerges.

In working on the app, I'll start with a simple test case
for the parser - reading files is easy and can come later.
I'll fake the first case or two and add the lexical
analyzer when it's easier than not doing it. Same goes
for the other objects that I predict I will need: lexical
token, tree node, etc.

Generating actual code is probably going to call for a
spike. I'm working with .NET so I can do one of two
things: use the built-in ability of .NET to emit IL,
or work directly in the format of a PE file and emit
code manually. Each has pros and cons and it will
probably take a few days of messing around to decide.

That's where I am... so far.

Charlie Poole
cpoole@...

Prof. Michael Cusumano of the Sloan School at MIT (Microsoft Secrets
and Competing on Internet Time) asked me to invite XPers to fill out
a software project survey. If we can get a significant number of XP
projects in there, we will learn a lot about how we stack up with the
rest of the industry and what we need to work on next.

If you have a few minutes, I'd appreciate your participation.
http://web.mit.edu/surveys/pearl/

Kent

I'm on my way back from the Cutter IT Summit. What a mind bending few
days. Here are a few random thoughts/impressions:
   * Rob Austin (Harvard BSchool) talked about managing agile projects
like a theater director directs a play. A book about the topic is due
soon, and I will be giving a copy to every manager of teams I coach.
   * Rob Thomsett is a wild man. I was pretty suspicious when I saw he
had a workshop entitled "Extreme Project Management". He earned a
worldwide, non-exclusive license to our beloved adjective by
terrifying me with a question from the floor while I was on a panel.
He has a book out on Radical Project Leadership (or Management) which
I have but have not yet read.
   * While Ed Yourdon was talking about "good enough software", I
realized that in XP we produce "big enough software". Instead of the
usual biz game of waiting until you have just enough stability to
ship, the business side of XP teams need to learn how to wait until
they have just enough scope to ship. "Big enough" puts the emphasis
on scope, where it belongs, instead of on quality, which isn't a
control variable.

Off to airplanes.

Kent

Charlie,

Interesting analogy with hiking. Since we live in the mountains and spend
most of the warm days on trails you're concept is very good. We don't have
much in the way of woods, since nearly everything worth going to is above
timber line. But the "search" pattern for peak-to-peak hikes works much the
same way. The true bearing is not worth much, but a relative bearing to the
next peak that will land us to a "known" side of the mountain, then an
adjustment from there to the summit.

BTW the "lost" analogy in the mountains is the same since most of the time
all peaks look alike from a distance, just like all the wooded trails, it's
only when you get closer - after several hours of hiking - they you may
discover you're on the wrong side.

[snip]

>When you're lost in the woods, and you know that the fire road where your
>car is parked is somewhere to the north, you head north of course. But you
>*don't* try to head for your car. If you did that, you'd most likely
>reach the road somewhere, but might not know which way to walk. So you
>head a little east (or west, if that's more convenient) of north. Now
>when you reach the road, you can confidently turn left (or right) and
>expect to shortly find your car.
>
>Similarly, since it's hard to do just the right amount of architecture up
>front, we need to aim either high or low. Aiming low is more convenient
>for two reasons. First, we avoid doing work that may not be needed. Second,
>and perhaps more important, teams seem to have more trouble dropping those
>practices which are not pulling their weight than they do adding new ones.
>
>Based on your comments in other threads, I suspect this is what you're
>doing. You seem to be a bit heavy on architecture as compared to many
>other folks here, but it sounds as if you're tons lighter than other
>people doing similar things.

I rationalize this as a domain influence, since in the ERP world many
decisions are irrevocable, erring on the heavy side produces lower risk than
moving forward only to discover there is missing information. To stretch the
analogy a bit, hiking in the mountains can have disastrous results - death
at times - if one is not prepared for all events, even those that seem very
unlikely to flatlanders. It's snowing as I type on what was a nice spring
day yesterday. Wouldn't want to be on the side of Niwot Ridge
http://culter.colorado.edu:1030/exec/sdlmetpage.pl.
>
>Charlie

Glen

dhemeryy wrote:
>
> Hi Carl,
>
> > My own preference, and I'm sorry I can't remember whether I saw this
> > somewhere or came up with it myself, is to call this a _Test_ of
> > Concept.  "Proof" to me strongly suggests that you already know the
> > outcome - far better to undertake such things open-minded, seems to
> > me.
>
> See definitions 4 and 3a at <http://www.dictionary.com/search?q=proof>.
>
I liked  defn 6, which was seriously off-topic. Other examples in common
English usage--

the proof of the pudding is in the eating. smelling gives you some idea,
but if you really want to know how good it is, there's only one sure way
of getting the authoritative knowledge.

the exception proves the rule. you want to know how/when to apply the
rule, look for cases where it does NOT  apply. This usage also carries
some suggestion that the rule might fail the test--if there are too many
exceptions, the rule is useless.

in making yeast-based bread, one starts by verifying that the yeast is
still alive. Put the yeast into some sugar water, if it bubbles it's OK.
this is known as 'proofing' the yeast.

Returnig to topic, I've always heard this called a   "Proof of COncept"
at least until I read XP, where it is likely to be called a spike.

Around Wednesday, May 1, 2002, 12:56:14 PM, dhemeryy wrote:

> By "architectural decision," I mean
> any design decision that significantly affects the system's quality
attributes.

> By "design decision," I mean a decision that either (1) selects
> elements of technology for inclusion in the system, or (2) defines
> how those elements interact to carry out the system's
> responsibilities.

> Given my revised definition, what do you think now?  Can you think of any
architectural decisions that
> don't fit my definition?  Can you think non-architectural decisions that do
fit it?

I think that every design decision now fits your definition of
architectural decision. If that's what you had in mind, I think you've
got it.

Ron Jeffries
www.XProgramming.com
Don't be afraid of pair programming:
You're not as good as you think you are, but
You're not as bad as you fear.

Adding to Kent,

In Robert Austin and Richard Nolan's 1998 seminal paper (at least seminal
for us folks in the field) titled "How to Manage ERP Projects," many of the
described practices would now be considered "agile." Much of Austin's work
is still "new" to the ears of the end users, but agile ERP deployment is
gaining understanding slowly.

Glen B. Alleman
Niwot Ridge Consulting
4347 Pebble Beach Drive
Niwot, Colorado 80503
PO Box 8657
Breckenridge, CO 80424
+1.720.406.9164 Office
+1.720.406.9293 Fax
+1.720.641.0980 Worldwide Mobile
galleman@... <mailto:galleman@...>
www.niwotridge.com <http://www.niwotridge.com/>


>-----Original Message-----
>From: kentlbeck [mailto:kentbeck@...]
>Sent: Wednesday, May 01, 2002 1:34 PM
>To: extremeprogramming@yahoogroups.com
>Subject: [XP] Cutter IT Summit
>
>
>I'm on my way back from the Cutter IT Summit. What a mind bending few
>days. Here are a few random thoughts/impressions:
>  * Rob Austin (Harvard BSchool) talked about managing agile projects
>like a theater director directs a play. A book about the topic is due
>soon, and I will be giving a copy to every manager of teams I coach.
>  * Rob Thomsett is a wild man. I was pretty suspicious when I saw he
>had a workshop entitled "Extreme Project Management". He earned a
>worldwide, non-exclusive license to our beloved adjective by
>terrifying me with a question from the floor while I was on a panel.
>He has a book out on Radical Project Leadership (or Management) which
>I have but have not yet read.
>  * While Ed Yourdon was talking about "good enough software", I
>realized that in XP we produce "big enough software". Instead of the
>usual biz game of waiting until you have just enough stability to
>ship, the business side of XP teams need to learn how to wait until
>they have just enough scope to ship. "Big enough" puts the emphasis
>on scope, where it belongs, instead of on quality, which isn't a
>control variable.
>
>Off to airplanes.
>
>Kent

Hi Ron,


> > By "architectural decision," I mean
> > any design decision that significantly affects the system's
> > quality attributes.

...

> I think that every design decision now fits your definition of
> architectural decision. If that's what you had in mind, I think
> you've got it.

The word "significantly" is key.  Though all design decisions affect
quality attributes, the effects can have differing significance.
Design decisions that have very large effects are definitely
architectural decisions.  The ones that have very small effects are
definitely not architectural.  The ones in between are more or less
architectural, depending on their significance.

Dale

Glen:

> Well this is interesting. Could I conjecture that Agile development and
> therefore XP is NOT applicable to ERP system integration projects?

You can conjecture all you like. I won't keep you. ;->

The thing is, I don't really know what an "ERP system integration"
is, so I can't answer that question on an informed basis. If you are
kind enough to educate me first, I will attempt to answer.

> >I have no reason to believe that either firm has less of a need for
> >disentrenchment than the other.
>
> I'm exactly clear on why architecture is associated with disentrenchment?

Simply because entrenchment masquerading as "architecture" is all too
often a harbinger of project failure. (Charlie's "war story" about
i18n is relevant.)

> >I expect that a firm with 10K users worldwide which has standardized
> >on SAP could get to regret it.
>
> Amy suggestion as to why this would be the case?

Say SAP goes out of business...

> >A firm with 10K users which has only
> >entrenched the use of HTML and HTTP is better off, in my book.
>
> Again any suggestion as to why?

Well, who would have to go out of business, in order that HTML and
HTTP be no longer "supported" technologies ? Or more generally what
would have to happen for that to happen ?

> >I'm saying this, not in spite of, but *because* of, my utter lack of
> >knowledge about SAP.
>
> Oh now I understand why those conjecture are made ;>)!!!

OK, imagine you have trouble understanding some minor detail of the
HTTP protocol. Then imagine you have trouble understanding some minor
detail of the SAP platform. Please research the compared costs of
filling in this minor understanding gap in either situation, taking
into account my own knowledge of one and ignorance of the other, and
the mechanics of a market economy driven by supply and demand.

-[Morendil]-
We all live in a yellow subroutine.

Glen,

> Interesting analogy with hiking. Since we live in the mountains and spend
> most of the warm days on trails you're concept is very good. We don't have
> much in the way of woods, since nearly everything worth going to is above
> timber line. But the "search" pattern for peak-to-peak hikes
> works much the
> same way. The true bearing is not worth much, but a relative
> bearing to the
> next peak that will land us to a "known" side of the mountain, then an
> adjustment from there to the summit.

It's a general pattern I learned as a boy scout - works for wooded hills,
marshes, deserts, mountains or whatever. Substitute river, ridge line,
tree line, etc for the road.

> >Based on your comments in other threads, I suspect this is what you're
> >doing. You seem to be a bit heavy on architecture as compared to many
> >other folks here, but it sounds as if you're tons lighter than other
> >people doing similar things.
>
> I rationalize this as a domain influence, since in the ERP world many
> decisions are irrevocable, erring on the heavy side produces
> lower risk than
> moving forward only to discover there is missing information. To
> stretch the
> analogy a bit, hiking in the mountains can have disastrous results - death
> at times - if one is not prepared for all events, even those that
> seem very
> unlikely to flatlanders. It's snowing as I type on what was a nice spring
> day yesterday. Wouldn't want to be on the side of Niwot Ridge
> http://culter.colorado.edu:1030/exec/sdlmetpage.pl.

Hey wait a minute! That's *my* analogy. :-)

Back in the software development world, I'd like to spell out a distinction
which you're familiar with but hasn't shown up in this thread yet. I have
some
experience with systems that can have serious consequences if done wrong -
up
to and including death. Doing *good* design and planning is essential to
reducing those risks. Doing *more* does not necessarily have the same
affect,
although it is sometimes useful to those who want to avoid the risk of being
*blamed* for failure.

Charlie Poole
cpoole@...


I know you know the difference, but

> -----Original Message-----
> From: Laurent Bossavit [mailto:laurent@...]
>
> The thing is, I don't really know what an "ERP system integration"
> is, so I can't answer that question on an informed basis. If you are
> kind enough to educate me first, I will attempt to answer.

"ERP system integration"  is just a lots of little system integrations.


> > Amy suggestion as to why this would be the case?
>
> Say SAP goes out of business...

...someone will buy SAP to pick up the maintenance contracts.


> > >A firm with 10K users which has only
> > >entrenched the use of HTML and HTTP is better off, in my book.
> >
> > Again any suggestion as to why?
>
> Well, who would have to go out of business, in order that HTML and
> HTTP be no longer "supported" technologies ? Or more generally what
> would have to happen for that to happen ?

Support of SAP technology is not dependent on SAP being in business.


> OK, imagine you have trouble understanding some minor detail of the
> HTTP protocol. Then imagine you have trouble understanding some minor
> detail of the SAP platform. Please research the compared costs of
> filling in this minor understanding gap in either situation, taking
> into account my own knowledge of one and ignorance of the other, and
> the mechanics of a market economy driven by supply and demand.

For your line of argument, it's not the protocols that matter, it's how
their implementations behave. Having spent a lot of time on HTTP, it's
clear to me that having an open protocol is a big win, but you need to
know how the machinery behaves in the field. Because the protocol is
open there are more flavours of machinery to know about. You'd be
surprised at the amount of implementation specific garbage that's sent
around the Web, but it all works well enough, as does SAP. Open
protocols make no guarantees wrt to futureprooofing.

Bill de hÓra

Around Wednesday, May 1, 2002, 11:34:55 AM, J. B. Rainsberger wrote:

> Quoting extremeprogramming@yahoogroups.com:

>>    From: Ron Jeffries <ronjeffries@...>
>>
>> Around Monday, April 29, 2002, 1:42:54 PM, J. B. Rainsberger wrote:
>>
>> > Team          W   L   Pct   GBL
>> > Toronto       6   2  .750    --
>> > Baltimore     5   3  .625     1
>> > Boston        5   4  .556     1 1/2
>> > New York      3   5  .375     3
>> > Tampa Bay     1   6  .143     4 1/2
>>
>> Here's the next installment. It's a long one, not least because it has
>> a complete listing.
>>
>> ==========================================
>>
>> Well, OK, what shall I do now? There aren't really any interesting
>> problems left that I can see.

> OK, this is an interesting statement. Let's review what you have so far --
even
> by the end of this session:

> * Games back is computed, although the sign is wrong. Trailers are currently
> negative-n games back, rather than n games back.

I thought I fixed that. Isn't the report right? Even if it isn't, it's
not an interesting problem, since I'll just have to reverse the guys
on opposite sides of a subtract ...

> * Sort by winning percentage works.
> * Leader is correctly identified.
> * Can process a file that's not quite the format required.

>>From your comment, what's not done is not "interesting" to you. I think if you
> can describe why, that would be the central thing to learn from you in this
> exercise. What makes the things you haven't done yet "uninteresting" compared
> to the things you've already done which are "interesting". Thanks!

> What is not done:

> * Categorizing teams into divisions and leagues.

This isn't interesting for two reasons: first and foremost, I don't
have the data defining divisions and leagues. Second, whatever it is,
it'll be a partition or two on the input data, so the ultimate report
will consist, I expect, of a loop over league, loop over division,
select members, print the standard report. Note that my report reports
on any collection of teams, so I'm sure it'll work if fed with the
right teams.

> * Reporting on the leaders within each division.

I don't have a story for this, do I?

> * Correct formatting.

Nitty-gritty grunt work. Nothing to learn, just screw with it. It's
all about padding the fields to the right size, and some messing
around to get 1.5 to print as 1 1/2.

> * Process the original input format requested.

Grunt work. As defined the input looks irritating to parse, since
there is no punctuation. The input looks like team name score-score
team name, and for all I know the team name can have numbers in it. If
it's really <alphaspaced><number><dash><number><alphaspaced> it won't
be too hard. It's about a regex away from easy.


I'll comment here on what I did. I was chatting with Chet about it at
lunch today. I'm not sure whether or not there was great (but hidden)
skill in deciding what to attack.

It might have been more XPish to have started from an input file and
produced the report test first. Instead, I zeroed in on the Team
concept as a holder for the win/loss record. Once that was done, there
were a few interesting things to do: get enough data into teams to
create them; compare them to get games back; compute their percentage
of wins. Then the report's interesting issues are finding the leader,
and sorting in the right order. The rest of reporting is iterate over
the collection print the line, just like every other report in the
universe.

What I was trying to do ... what I'm always trying to do ... is to see
what part of the problem meets two criteria:

   1. I don't know how to do it.
   2. It looks bite-size.

In this case I was sure that "collection of teams", which is an
instance of a pattern "collection of detail objects", was close enough
to a good answer to go ahead with it. That surely takes some kind of
experience and skill to get right. It seemed obvious to me, but it's
not clear to me whether it would seem obvious to other programmers of
differing experience.

In other times or problems, I might have started with a straight "fake
it till you make it" off the original input, but I don't think so.

Another way to go might have been to build teams that just knew their
games back by magic, but that didn't occur to me until now and I'm not
sure it would have made sense. It seemed natural to create a team with
what I knew (win/loss) and go from there.

So, was it a good way, one that I'd write a book about? Maybe not. It
was my way, and I hope it's interesting and/or useful to people to
observe and think about.

Comments and questions are welcome ...

===================
>> That looks about right. Now let's see about getting GBL. That'll be
>> tricky, I will have to pass in the leader team. (I don't know which
>> team is leader ... never tested that feature. I guess I'm about to.)

> Why not a separate unit test for this feature?

Well, probably there should be one. I expect that it'll come out in a
later acceptance test. Generating weird data for this thing is beyond
me as a non-lover of baseball. The code for leader is simple, so at
the time I thought it worked. Applied the principle of testing
everything that could possibly break. Worth noting, since those are
the places that break. ;->

> PS: I apologize for not providing better AT data. I'm still learning to be a
> customer, too. :)

Chet remarked at California Pizza Kitchen that he thought the
conversation / negotiation between customer and programmer was an
interesting part of this exchange. Chet, say more about that?

Ron Jeffries
www.XProgramming.com
Adapt, improvise, overcome.
   --Gunnery Sergeant Tom Highway (Heartbreak Ridge)

Laurent, responding to Glen, happened to quote me:

> > I'm exactly clear on why architecture is associated with
> disentrenchment?
>
> Simply because entrenchment masquerading as "architecture" is all too
> often a harbinger of project failure. (Charlie's "war story" about
> i18n is relevant.)

Except that my story is an example of entrenchment in a decision about
the details of how coding is done. I accept that "entrenched decisions"
often occur in an architectural context but architecture has no monopoly
on them. For example, I've seen projects negatively impacted by bad
policies on purchasing equipment, which had become entrenched within
the company.

I think it's within the spirit of XP to perform a mental experiment
of doing away with architecture. That seems to be what you're doing.
It's also within our spirit to try to take it over and make it be
something that works for us. That's what I'd like to do.

Charlie Poole
cpoole@...

Around Wednesday, May 1, 2002, 3:33:36 PM, kentlbeck wrote:

>   * Rob Austin (Harvard BSchool) talked about managing agile projects
> like a theater director directs a play. A book about the topic is due
> soon, and I will be giving a copy to every manager of teams I coach.

Couldn't find this on Amazon, so couldn't set up a reservation. I hope
when this comes out someone will give a shout.

>   * Rob Thomsett is a wild man. I was pretty suspicious when I saw he
> had a workshop entitled "Extreme Project Management". He earned a
> worldwide, non-exclusive license to our beloved adjective by
> terrifying me with a question from the floor while I was on a panel.
> He has a book out on Radical Project Leadership (or Management) which
> I have but have not yet read.

Book ordered. What was the question?

>   * While Ed Yourdon was talking about "good enough software", I
> realized that in XP we produce "big enough software". Instead of the
> usual biz game of waiting until you have just enough stability to
> ship, the business side of XP teams need to learn how to wait until
> they have just enough scope to ship. "Big enough" puts the emphasis
> on scope, where it belongs, instead of on quality, which isn't a
> control variable.

Very interesting. The whole "good enough" thing ticks me off, as
anyone who has been in the way of my bug database discussion has
experienced. Perfect is good enough. Anything less and there's
guaranteed to be a bug in there that the bastxxxxcustomer wants out.
Might as well just make it as good as we can, save all that debugging
time.


Sounds like I made a mistake in not attending. Not my first. I hope
not my last.  Thanks for the report!

Ron Jeffries
www.XProgramming.com
It's easier to act your way into a new way of thinking
than to think your way into a new way of acting.  --Millard Fuller

Around Wednesday, May 1, 2002, 6:09:44 PM, dhemeryy wrote:

>> I think that every design decision now fits your definition of
>> architectural decision. If that's what you had in mind, I think
>> you've got it.

> The word "significantly" is key.  Though all design decisions affect
> quality attributes, the effects can have differing significance.
> Design decisions that have very large effects are definitely
> architectural decisions.  The ones that have very small effects are
> definitely not architectural.  The ones in between are more or less
> architectural, depending on their significance.

So if the decision is a 6, it's architectural, but if it is a 5 or
less, it's not. Got it! ;->

Ron Jeffries
www.XProgramming.com
XP says: Don't just sit on your DUF, do something. Get some feedback.