eXtreme Programming San Diego's next meeting is this Thursday, July 2nd.
John Arrizza will be giving an introduction to XP from 6-7:30PM, and we will
have optional beer & food over further discussion afterwards, at the same
location.

In his talk, "Introduction to XP", John will contrast Extreme Programming
with typical Software Engineering methodologies to show that XP has,
inherent in it's core principles, solid, well-known Software Engineering
activities. He will then present the 12 XP principles, showing an overview
of a typical XP development cycle, all followed by a question and answer
session. This presentation will target Software Development Managers or
Developers who are familiar with development issues and problems, but is
open to all who are looking at XP to help solve their software development
problems, as well as those who are just curious about what XP is all about.

This is an open meeting; invite anyone you think might be interested. Please
RSVP to joonspoon@... if you plan to attend.

Please note that this meeting will take place at our NEW location at The
Linkery in North Park. Here are directions:
http://www.xpsd.org/cgi-bin/wiki?TheLinkery
And to whet your appetite, The Linkery are having a special beer/food
pairing tomorrow: http://thelinkery.com/blog/summer-beer-pairing/

-------------------
http://xpsd.org
http://www.arrizza.com/

Crossposting here by request ...

I followed-up on my original blog-post with an entry on
self-organization and complexity, and another on self-organizing teams
in particular.

What may be of most interest however is the is the list of about three
dozen or so online resources on the subject.

Interested parties can view it at
http://blog.bradapp.net/search/label/Self-Organization

--
Brad Appleton <brad {AT} bradapp.net>
    Agile CM Environments (http://blog.bradapp.net/)
    & Software CM Patterns (www.scmpatterns.com)
"And miles to go before I sleep" -- Robert Frost

I've been reading a lot on this subject lately, and wanted to mention one of
the presuppositions that I missed when I first started reading some of the
articles on the subject:  to be self-organizing, a team needs to be past the
Storming phase in Tuckman's Forming, Storming, Norming, Performing model.
I'd love to know how to help a team go through these phases quickly... but
it seems to mostly be related to individual desires to open up, or not.

On Thu, Jul 2, 2009 at 6:51 PM, Brad Appleton <Brad.Appleton@...>wrote:

>
>
> Crossposting here by request ...
>
> I followed-up on my original blog-post with an entry on
> self-organization and complexity, and another on self-organizing teams
> in particular.
>
> What may be of most interest however is the is the list of about three
> dozen or so online resources on the subject.
>
> Interested parties can view it at
> http://blog.bradapp.net/search/label/Self-Organization
>
> --
> Brad Appleton <brad {AT} bradapp.net>
> Agile CM Environments (http://blog.bradapp.net/)
> & Software CM Patterns (www.scmpatterns.com)
> "And miles to go before I sleep" -- Robert Frost
>
>



--
D. André Dhondt
mobile: 001 33 671 034 984


[Non-text portions of this message have been removed]

Dear all,

i want to share with you the idea of my PhD. research

the idea is that Kent Beck says that XP works fine for projects of 10 to 20
programmers, but not for the big ones.

our research is that some modifications on XP may well make it fine with big
ones. these modifications are as follows:

1. XP focuses on tacit knowledge sharing but on explicit, we need to increse our
focus on explicit knowledge by increasing the amount of documentation but
rationally.

2. if we add an analysis phase per iteration we increase the amount of explicit
knowledge sharing with customers.

3. we introduce the concept of pair development over instead of pair
programming, that is instead of doing the programming in pairs, we do the
analysis, design, and coding in pairs.

can i hear from you your point of view on these points.

thanks

zaidoun alzoabi

Hello Zaidoun,

When you say research, do you mean that you have found a statistically
significant difference in the success rates of large teams that are
doing the three practices you mention than those not?

I would like to hear more about the analysis phase you mention as
well.  Do you mean a fixed period of time during which analysis for
all stories planned for the iteration takes place?  If so, I would
argue that a team doing that will have drifted pretty far from my
understanding of XP.

chet

Thursday, July 2, 2009, 11:48:34 PM, you wrote:

> Dear all,

> i want to share with you the idea of my PhD. research

> the idea is that Kent Beck says that XP works fine for projects of
> 10 to 20 programmers, but not for the big ones.

> our research is that some modifications on XP may well make it fine
> with big ones. these modifications are as follows:

> 1. XP focuses on tacit knowledge sharing but on explicit, we need
> to increse our focus on explicit knowledge by increasing the amount of
documentation but rationally.

> 2. if we add an analysis phase per iteration we increase the amount
> of explicit knowledge sharing with customers.

> 3. we introduce the concept of pair development over instead of
> pair programming, that is instead of doing the programming in pairs,
> we do the analysis, design, and coding in pairs.

> can i hear from you your point of view on these points.

> thanks

> zaidoun alzoabi




--
Best regards,
  Chet Hendrickson                          mailto:lists@...
  Check out our upcoming CSM Plus courses @
http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28

Hello, zaidoun.

My biggest and first question is to understand the extent to which
you and your colleagues have actually done XP as it exists.

Some smaller items below:

On Thursday, July 2, 2009, at 11:48:34 PM, you wrote:

> our research is that some modifications on XP may well make it
> fine with big ones. these modifications are as follows:

> 1. XP focuses on tacit knowledge sharing but on explicit, we need
> to increse our focus on explicit knowledge by increasing the
> amount of documentation but rationally.

So when you refer to "explicit knowledge", I take it you are
referring not to things that people know, but to things that are
written down?

> 2. if we add an analysis phase per iteration we increase the
> amount of explicit knowledge sharing with customers.

How would that improve the knowledge situation compared to having
the developers and customers actually communicating directly,
writing down what they want to? (That is what already happens.)

> 3. we introduce the concept of pair development over instead of
> pair programming, that is instead of doing the programming in
> pairs, we do the analysis, design, and coding in pairs.

I think that programming = analysis+design+coding. Therefore I see
no difference between what you are calling pair development and what
we call pair programming. What am I missing?

Regards,

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
That's my opinion and I agree with it. -- Julio Santos

PhD research should go beyond what has already been done.  How would
your research surpass Balancing Agility and Discipline By Barry W
Boehm, Richard Turner?

http://books.google.com/books?&id=MWhXwkHsS0gC&oi=fnd&pg=PR15&dq=%22Boehm%22+%22\
Balancing+agility+and+discipline:+A+guide+for+the+perplexed%22

http://www.fsktm.upm.edu.my/~rodziah/sak5108/p44-beck.pdf

How would you go about establishing that these changes actually
improve the value and quality of software produced by large teams in
practice?

Steven Gordon, PhD

On Thu, Jul 2, 2009 at 8:48 PM, zdnfa<zdnfa@...> wrote:
>
>
> Dear all,
>
> i want to share with you the idea of my PhD. research
>
> the idea is that Kent Beck says that XP works fine for projects of 10 to 20
> programmers, but not for the big ones.
>
> our research is that some modifications on XP may well make it fine with big
> ones. these modifications are as follows:
>
> 1. XP focuses on tacit knowledge sharing but on explicit, we need to increse
> our focus on explicit knowledge by increasing the amount of documentation
> but rationally.
>
> 2. if we add an analysis phase per iteration we increase the amount of
> explicit knowledge sharing with customers.
>
> 3. we introduce the concept of pair development over instead of pair
> programming, that is instead of doing the programming in pairs, we do the
> analysis, design, and coding in pairs.
>
> can i hear from you your point of view on these points.
>
> thanks
>
> zaidoun alzoabi
>

D. André Dhondt wrote:
> I've been reading a lot on this subject lately, and wanted to mention one of
> the presuppositions that I missed when I first started reading some of the
> articles on the subject:  to be self-organizing, a team needs to be past the
> Storming phase in Tuckman's Forming, Storming, Norming, Performing model.
> I'd love to know how to help a team go through these phases quickly... but
> it seems to mostly be related to individual desires to open up, or not.

Andre, I've never found the Tuckman model very helpful for enabling
teams.  Just because they're storming, it doesn't mean they'll proceed
to norming.  You might look at the Drexler-Sibbet Team Performance
Model.  I was first introduced to this by Esther Derby and wrote
http://blog.gdinwiddie.com/2008/12/03/aye-2008-the-magic-chemistry-of-teams/
on it.

   - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

The reason for small teams is because communication breaks down as
teams size up. In other words communication is maximized by
intentionally keeping team size small. I'm not sure why you would want to size
up the teams. It leaves me a little puzzled.

I would love for you to show us a new balance of written and oral communication
using old (paper, word, CASE) or new (blogs, wikis, mail, social nets) tech so
well that we don't need small team size in order to maintain rich, full
communication bandwidth and can still get immediate answers to our questions and
concerns.

If you have the right idea, then you will have made a contribution to the field.
We will all have learned something useful. We might even suffer small
degradations of individual pair productivity if they led to compensatory
whole-team productivity. It's all cost/benefit, I guess, but you can be assured
that all Pareto improvements are welcome.

If your idea does not work (ie, a return to document management in place of
development, wasteful phase-boundary ceremonies, higher overhead, decrease in
running tested features per iteration) then you will have confirmed something
that we believed all along.

There is NO downside to you doing this work.

Godspeed.

  Tim Ottinger
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/

On Fri, Jul 3, 2009 at 11:53 AM, Tim Ottinger<linux_tim@...> wrote:
>
>
>
> The reason for small teams is because communication breaks down as
> teams size up. In other words communication is maximized by
> intentionally keeping team size small. I'm not sure why you would want to
> size up the teams. It leaves me a little puzzled.
>
> I would love for you to show us a new balance of written and oral
> communication using old (paper, word, CASE) or new (blogs, wikis, mail,
> social nets) tech so well that we don't need small team size in order to
> maintain rich, full communication bandwidth and can still get immediate
> answers to our questions and concerns.
>
> If you have the right idea, then you will have made a contribution to the
> field. We will all have learned something useful. We might even suffer small
> degradations of individual pair productivity if they led to compensatory
> whole-team productivity. It's all cost/benefit, I guess, but you can be
> assured that all Pareto improvements are welcome.
>
> If your idea does not work (ie, a return to document management in place of
> development, wasteful phase-boundary ceremonies, higher overhead, decrease
> in running tested features per iteration) then you will have confirmed
> something that we believed all along.
>
> There is NO downside to you doing this work.

No downside for us, maybe.  However, they do not grant PhDs for
confirming something that is generally believed, especially if the
basis of that confirmation is just one idea that did not work.

>
> Godspeed.
>
> Tim Ottinger
> http://agileinaflash.blogspot.com/
> http://agileotter.blogspot.com/
>

Along the same lines, to what area of knowledge
would a work on Ph.D. thesis on XP improvement
belong? Psychology? Business administration?

Regards,

Slava Imeshev

On Thu, Jul 2, 2009 at 8:48 PM, zdnfa<zdnfa@...> wrote:
>
>
> Dear all,
>
> i want to share with you the idea of my PhD. research
>
> the idea is that Kent Beck says that XP works fine for projects of 10 to 20
> programmers, but not for the big ones.
>

10-20 programmers is /huge/. In my experience XP teams are successful
with far fewer.

> our research is that some modifications on XP may well make it fine with big
> ones. these modifications are as follows:
>

Why? Why would you want your team to be bigger than that? What
advantage does having a large team provide?

> 1. XP focuses on tacit knowledge sharing but on explicit, we need to increse
> our focus on explicit knowledge by increasing the amount of documentation
> but rationally.
>

Is running code with tests a form of "explicit knowledge?" Might we
perhaps be more successful with more of that rather than more
documentation (rational or otherwise?)

> 2. if we add an analysis phase per iteration we increase the amount of
> explicit knowledge sharing with customers.
>

We analyze continuously. How would separating analysis from other
day-to-day activities give us any advantage?

> 3. we introduce the concept of pair development over instead of pair
> programming, that is instead of doing the programming in pairs, we do the
> analysis, design, and coding in pairs.
>

We already do this. Analysis, design, and coding are all part of the
existing pair programming/TDD paradigm.

 
 
Dear all,
thanks for your reply
 
your questions could be answered through reading this article
www.ieeexplore.ieee.org/iel5/4520396/4529902/04530347.pdf
 
but for te time I will answer your main questions;
 

We have used XP in a big project that intended to computerize the tax autority
processes in Syria. The system is considered very complex due to the many laws,
regulations, decrees, and procedures used.
we had to modify the lifecycle of XP in order to deal with the complexity of the
system, this happened through adding a clear analysis phase before any release,
and breaking the system into smaller modules each taken by pair developers.
in the analysis phase we used formal meeting sessions with tax experts and
managers and we used DFD and ERD to communicate with them.
These people did not have time to communicate with us on frequent basis and in
many cases they had conflicting ideas, this why we needed formal communication
with them.
pair development is different from pair programming as the pair here will not
only sit at the same computer and do the coding, our pair will do the analysis
for their module, desing the solution, integrate with the design of other pairs
modules and then do the coding development=analysis+desing+programming+testing
the research goes beyond Boehm and Turner "balancing Agility with Discipline" by
saying how to do that in reality, and that too by focusing on Nonake spiral
knowledge sharing model SECI 
best regards




[Non-text portions of this message have been removed]

Dear all,
thanks for your reply

your questions could be answered through reading this article
www.ieeexplore.ieee.org/iel5/4520396/4529902/04530347.pdf

but for te time I will answer your main questions;

1. We have used XP in a big project that intended to computerize the tax
autority processes in Syria. The system is considered very complex due to the
many laws, regulations, decrees, and procedures used.
2. we had to modify the lifecycle of XP in order to deal with the complexity of
the system, this happened through adding a clear analysis phase before any
release, and breaking the system into smaller modules each taken by pair
developers.
in the analysis phase we used formal meeting sessions with tax experts and
managers and we used DFD and ERD to communicate with them.
3. These people did not have time to communicate with us on frequent basis and
in many cases they had conflicting ideas, this why we needed formal
communication with them.

4. pair development is different from pair programming as the pair here will not
only sit at the same computer and do the coding, our pair will do the analysis
for their module, desing the solution, integrate with the design of other pairs
modules and then do the coding development=analysis+desing+programming+testing

5. the research goes beyond Boehm and Turner "balancing Agility with Discipline"
by saying how to do that in reality, and that too by focusing on Nonake spiral
knowledge sharing model SECI
best regards

On Fri, Jul 3, 2009 at 8:53 PM, zdnfa<zdnfa@...> wrote:
>
>
> Dear all,
> thanks for your reply
>
> your questions could be answered through reading this article
> www.ieeexplore.ieee.org/iel5/4520396/4529902/04530347.pdf
>

I'm not currently a member of IEEE, and I'm not inclined to pay to
read this. However, I wanted to point out that your abstract is
incorrect. The statement, "agile methods suffer from the lack of
disciplined planning" shows a lack of fundamental understanding of the
XP approach. Also, XP is neither the oldest nor the most well known of
the Agile methods. At least Scrum and FDD predate XP, and Scrum is
more widely adopted and understood. Further, you stated that your
intent was to extend XP beyond the limit of "ten to twenty developers"
and yet your study only used eleven.

On Fri, Jul 3, 2009 at 8:49 PM, zaidoun alzoabi<zdnfa@...> wrote:
>
>
>
>
> Dear all,
> thanks for your reply
>
> your questions could be answered through reading this article
> www.ieeexplore.ieee.org/iel5/4520396/4529902/04530347.pdf
>
> but for te time I will answer your main questions;
>
>
> We have used XP in a big project that intended to computerize the tax
> autority processes in Syria. The system is considered very complex due to
> the many laws, regulations, decrees, and procedures used.
> we had to modify the lifecycle of XP in order to deal with the complexity of
> the system, this happened through adding a clear analysis phase before any
> release, and breaking the system into smaller modules each taken by pair
> developers.

Every project encounters obstacles.  In the vast majority of cases,
the obstacles can be cleared given determination, courage and
organizational support (and sometimes small adaptations of the
methodology).  In a few cases, the team may have to make major changes
to their methodology instead.

Just because one particular team in one particular circumstance did
not have the determination, courage and organizational support to make
XP work does not necessarily mean XP could not have been made to work.
  If you had brought in an experienced XP consultant who was unable to
find a way to make XP work, then maybe there would be some credibility
to your premise.

Did the team deliver working software periodically to these "tax
experts and managers" for feedback and use that feedback to improve
the software and the shared understanding of the requirements (and
even modify future requirements or their relative priority)?  If so,
how frequently did this feedback loop occur.  If this feedback loop
did not occur monthly at the very least, then the team did not do a
modified form of XP or even Agile, but instead just gave up and
reverted to Waterfall when they encountered resistance.

That waterfall can work a little better when the phases are done by
pairs working together would not be a surprising result to the Agile
world, but maybe the Waterfall community would find it significant.

Tim Ottinger
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/



----- Original Message ----
> From: Adam Sroka <adam.sroka@...>
> To: extremeprogramming@yahoogroups.com
> Sent: Saturday, July 4, 2009 1:53:47 AM
> Subject: Re: [XP] Preparing XP for the big projects
>
> On Thu, Jul 2, 2009 at 8:48 PM, zdnfawrote:
> >
> >
> > Dear all,
> >
> > i want to share with you the idea of my PhD. research
> >
> > the idea is that Kent Beck says that XP works fine for projects of 10 to 20
> > programmers, but not for the big ones.
> >
>
> 10-20 programmers is /huge/. In my experience XP teams are successful
> with far fewer.
>
> > our research is that some modifications on XP may well make it fine with big
> > ones. these modifications are as follows:
> >
>
> Why? Why would you want your team to be bigger than that? What
> advantage does having a large team provide?
>
> > 1. XP focuses on tacit knowledge sharing but on explicit, we need to increse
> > our focus on explicit knowledge by increasing the amount of documentation
> > but rationally.
> >
>
> Is running code with tests a form of "explicit knowledge?" Might we
> perhaps be more successful with more of that rather than more
> documentation (rational or otherwise?)
>
> > 2. if we add an analysis phase per iteration we increase the amount of
> > explicit knowledge sharing with customers.
> >
>
> We analyze continuously. How would separating analysis from other
> day-to-day activities give us any advantage?
>
> > 3. we introduce the concept of pair development over instead of pair
> > programming, that is instead of doing the programming in pairs, we do the
> > analysis, design, and coding in pairs.
> >
>
> We already do this. Analysis, design, and coding are all part of the
> existing pair programming/TDD paradigm.
>
>
> ------------------------------------
>
> 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.comYahoo! Groups Links
>
>
>

zdnfa wrote:

> the idea is that Kent Beck says that XP works fine for projects of 10 to 20
programmers, but not for the big ones.

How about you locate the 10 biggest, most successful projects you can, and then
study what they actually did? Not what ideology they worshiped!

> 1. XP focuses on tacit knowledge sharing but on explicit, we need to increse
our focus on explicit knowledge by increasing the amount of documentation but
rationally.

Look at online repositories like GitHub. They share a huge amount of data, all
of them implicitly, with minimal documentation. This does not always work
perfectly - like anything in Open Source land - but when it does the results are
amazing.

> 2. if we add an analysis phase per iteration we increase the amount of
explicit knowledge sharing with customers.

Why would spending a period of time guessing what the technical architecture
will be improve the knowledge sharing on the business side? Seems to me that
standardizing the storytests, like Cucumber does, would be more useful.

> 3. we introduce the concept of pair development over instead of pair
programming, that is instead of doing the programming in pairs, we do the
analysis, design, and coding in pairs.

The problem with that is pair programming without TDD and emergent design is
very painful. This is why most knowledge-work always was - and still is - from a
desk built for one.

Imagine, for example, pair Googling. One pair want to click on one citation,
while another pair wants to click on another. The friction simply is not worth
the slight benefit in synergy. The pair might as well Google for overlapping
topics, from two workstations, and then merge their findings!

> can i hear from you your point of view on these points.

Please do not go here:

    http://c2.com/cgi/wiki?BigAgileUpFront

--
    Phlip
    http://twitter.com/Pen_Bird

Here's a thought for ye Agile folk.

We've had YAGNI, You're Ain't Gonna Need It, as a tool to reduce the
weight of code that slows our ability to change, to be agile.

Here's another.

YAGDI You Are Gonna Debug It.

You may be perfectly Test Driven, you may have a perfect suite of unit
tests...

But if all those tests give you is "it failed", the first thing you
are going to do is scrabble around for more information.

So design your code, write your tests to expose enough information,
write KNOWING YOU WILL BE DEBUGGING THIS CODE.

'Cause the simple fact is you will be debugging that code. Probably
now, maybe next year, and certainly if, being agile, you ever change
it.

Often I merely need to look at either my log trace or my unit test
output and I know what the fault is.

My next step is to add an assertion either in the test, or the code
that will prove that I know what the bug is.

Then I fix it.

If I can't immediately tell where the bug is, I alter the design to
expose in the error messages, the log traces, the reports, the reasons
it behaved as it did.

Think of it as a story, a narrative. The person who cares should be
able to read the narrative of the systems behaviour.

The user who doesn't care, should just be told which log file to email
to support.



John Carter

We already have this, without the cute aphorism. At least Bob Martin
has spoken and written about it at length, and I think others have as
well.

We don't want to debug. We do want to write tests that each fail for
one specific reason so that when they fail we know precisely why they
failed.

We then want to see them fail and write the smallest possible piece of
code that will make them pass, then see them pass. At that point we
know:

1) That the test fails for the right reason.
2) That the test passes when we implement the right specific behavior.
3) Because the implementation is a simple as it could possibly be it
is extremely unlikely that it will fail for an unexpected reason. It
shouldn't attempt to do anything that we aren't already testing for.

Having said that, the debugger is not a bad thing per se, it's just
the idea of needing to figure out what code does after we've already
written it that is the problem. I know guys, particularly Smalltalkers
who made the transition to Java or C#, who actually like to code in
the debugger because it feels more like working in the "refactoring
browser" of that language.

On Sun, Jul 5, 2009 at 6:31 PM, John Carter<john.carter@...> wrote:
>
>
> Here's a thought for ye Agile folk.
>
> We've had YAGNI, You're Ain't Gonna Need It, as a tool to reduce the
> weight of code that slows our ability to change, to be agile.
>
> Here's another.
>
> YAGDI You Are Gonna Debug It.
>
> You may be perfectly Test Driven, you may have a perfect suite of unit
> tests...
>
> But if all those tests give you is "it failed", the first thing you
> are going to do is scrabble around for more information.
>
> So design your code, write your tests to expose enough information,
> write KNOWING YOU WILL BE DEBUGGING THIS CODE.
>
> 'Cause the simple fact is you will be debugging that code. Probably
> now, maybe next year, and certainly if, being agile, you ever change
> it.
>
> Often I merely need to look at either my log trace or my unit test
> output and I know what the fault is.
>
> My next step is to add an assertion either in the test, or the code
> that will prove that I know what the bug is.
>
> Then I fix it.
>
> If I can't immediately tell where the bug is, I alter the design to
> expose in the error messages, the log traces, the reports, the reasons
> it behaved as it did.
>
> Think of it as a story, a narrative. The person who cares should be
> able to read the narrative of the systems behaviour.
>
> The user who doesn't care, should just be told which log file to email
> to support.
>
> John Carter
>
>

On Sun, 5 Jul 2009, Adam Sroka wrote:

> We don't want to debug. We do want to write tests that each fail for
> one specific reason so that when they fail we know precisely why they
> failed.

This is insufficient in a couple of areas...

   * In well unit tested code, the remaining bugs are integration bugs.

   * If a bug escapes to the customer, how do you find and fix rapidly?

   * Agile is about making things easy to change.

     So if you pile in there with your boots on and write a test that
     implies sweeping changes underneath the hood.

     It fails. No problem.

     Then we make the Big Change under the hood. The unit tests light up
     like a Christmas tree.

     Even in places you didn't quite expect. That's OK too. That's why
     we brace things with Unit tests. To catch "those places that change
     effects, but we didn't expect".

     But then you left with, "Oh, that failed. I don't know why."

The small tiny change in Agile practices I'm suggesting is
this. Instead of writing a unit test assertion
       assert_equal( expected, result)
or and error message like
     error( "Failure");

Write each test assuming it will fail and now you're debugging it.

Write a little story about what you were trying to do and test, and
why you expect that result. Make the story executable.

What values did the test put into the code that generated result? What
is the internal state of the object that generated result. I often
override "to string" methods to print a readable summary of the
important state.

> Having said that, the debugger is not a bad thing per se, it's just
> the idea of needing to figure out what code does after we've already
> written it that is the problem.

Strangely enough I _very_ seldom use the debugger. Not because I'm
tech shy, I can surf the debugger along with (or better than) the best
of 'em.

I just find it's not the best tool.

What works better than a debugger at debugging?

Unit tests, precondition and invariant asserts in the code, unit test
logging traces, careful exception handling, descriptive and readable
"to string" methods and narrative error reporting that provides all
the info you need.

Whenever I describe unit testing to people, I tell'em that unit
testing is what you have always done.

You have always written a chunk of code, and then written something to
exercise it, and print the results out on the screen. You then eyeball
the results and say, Yip!  That was OK. (or not).

The difference is with unit testing is I'm asking you to record that
oracle, that knowledge, that expertise you have of whether a result is
"right" or not, as a program that others can run.

The small tweak to agile I'm suggesting now comes down to this...

If the test/assert/error were to fail/trigger/occur, what would we get
the debugger to print out, to understand the bug. And just encode that
knowledge, that expertise you have so the information is there on the
screen, the error report, the log trace when the test fails.


Because you are going to need it. May be not now, maybe not
tomorrow.




John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@...
New Zealand

Dear Zaidoun,

It sounds like you made a sensible local adaptation of XP for your
situation. That's what XPers do. The question of whether those adaptations
are more generally applicable is worth careful study. Please keep me
apprised of your progress.

Regards,

Kent Beck
Three Rivers Institute

   _____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of zaidoun alzoabi
Sent: Friday, July 03, 2009 8:49 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [good] [XP] Preparing XP for the big projects







Dear all,
thanks for your reply

your questions could be answered through reading this article
www.ieeexplore.ieee.org/iel5/4520396/4529902/04530347.pdf

but for te time I will answer your main questions;


We have used XP in a big project that intended to computerize the tax
autority processes in Syria. The system is considered very complex due to
the many laws, regulations, decrees, and procedures used.
we had to modify the lifecycle of XP in order to deal with the complexity of
the system, this happened through adding a clear analysis phase before any
release, and breaking the system into smaller modules each taken by pair
developers.
in the analysis phase we used formal meeting sessions with tax experts and
managers and we used DFD and ERD to communicate with them.
These people did not have time to communicate with us on frequent basis and
in many cases they had conflicting ideas, this why we needed formal
communication with them.
pair development is different from pair programming as the pair here will
not only sit at the same computer and do the coding, our pair will do the
analysis for their module, desing the solution, integrate with the design of
other pairs modules and then do the coding
development=analysis+desing+programming+testing
the research goes beyond Boehm and Turner "balancing Agility with
Discipline" by saying how to do that in reality, and that too by focusing on
Nonake spiral knowledge sharing model SECI
best regards

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

On Sun, Jul 5, 2009 at 9:46 PM, John Carter<john.carter@...> wrote:
>
>
> On Sun, 5 Jul 2009, Adam Sroka wrote:
>
>> We don't want to debug. We do want to write tests that each fail for
>> one specific reason so that when they fail we know precisely why they
>> failed.
>
> This is insufficient in a couple of areas...
>
> * In well unit tested code, the remaining bugs are integration bugs.
>

Hmmm... well tested code has integration tests too. In TDD I wouldn't
be compelled to integrate things without some sort of test that made
it necessary.

> * If a bug escapes to the customer, how do you find and fix rapidly?
>

Some folks would go immediately to the debugger, but a good TDDer
would write a test the failed due to the bug as soon as he was able to
reproduce it (Possibly even before.) Then it's a matter of making that
test pass.

> * Agile is about making things easy to change.
>

Agile is about accepting that things will change and having a
disciplined way of managing those changes when they occur. Making
changes "easier" isn't the goal per se. Well-designed designed code is
supposed to be easy to change. That is part of the definition of
well-designed code that even the BDUF guys use.

> So if you pile in there with your boots on and write a test that
> implies sweeping changes underneath the hood.
>
> It fails. No problem.
>
> Then we make the Big Change under the hood. The unit tests light up
> like a Christmas tree.
>

True, but we don't do that (Or, at least, we shouldn't.) We write
tests for small changes. If we need to make a big change we decompose
it into smaller changes so that we can proceed in a disciplined manner
(Precisely so that we don't find a bunch of failing tests the way you
describe. Although, it does happen.)

If we think a small change will break a lot of things then we might
need to refactor the tests before we proceed. Having a large number of
tests respond to a single intentional change is a smell. It is akin to
having similar behavior in multiple implementation classes.

> Even in places you didn't quite expect. That's OK too. That's why
> we brace things with Unit tests. To catch "those places that change
> effects, but we didn't expect".
>

That's one reason, but I think it is the least important one. At
least, to define the expected behavior, and to drive the design of the
code, are more significant. That's part of the reason for "BDD" - to
point out that TDD isn't really about testing. Having a full
regression suite is a happy side-effect of TDD but not a goal per se.

> But then you left with, "Oh, that failed. I don't know why."
>

I can't remember the last time this happened to me. I can remember
times when I wasn't immediately sure what to do to fix a broken test,
but I can't remember the last time (I was using TDD and) I didn't know
why the test was failing.

> The small tiny change in Agile practices I'm suggesting is
> this. Instead of writing a unit test assertion
> assert_equal( expected, result)
> or and error message like
> error( "Failure");
>
> Write each test assuming it will fail and now you're debugging it.
>

Yes. Again, this is not a new idea. Nearly every competent TDDer I
know writes tests whose assertions are specific to what they expect to
happen and whose results give information about what failed and why.
Often all that is necessary is to name the test well, but choosing the
right assertions is also important.

> Write a little story about what you were trying to do and test, and
> why you expect that result. Make the story executable.
>
> What values did the test put into the code that generated result? What
> is the internal state of the object that generated result. I often
> override "to string" methods to print a readable summary of the
> important state.
>

If the stringification is useful in some other context then this makes
sense. Otherwise you are violating SRP by making the class responsible
for testing/debugging/logging. It's potentially a better idea to
inspect the object reflectively if your language supports that.

>> Having said that, the debugger is not a bad thing per se, it's just
>> the idea of needing to figure out what code does after we've already
>> written it that is the problem.
>
> Strangely enough I _very_ seldom use the debugger. Not because I'm
> tech shy, I can surf the debugger along with (or better than) the best
> of 'em.
>
> I just find it's not the best tool.
>

I'm with you. I almost never use a debugger. When I do it's usually
because I am working with some legacy code that I don't understand
well, and I can't quite figure a way to test precisely what I want to
know.

I use a profiler just slightly more often just to see if I am doing
something silly (e.g. repeating an operation unnecessarily inside a
nested loop.)

> What works better than a debugger at debugging?
>
> Unit tests, precondition and invariant asserts in the code, unit test
> logging traces, careful exception handling, descriptive and readable
> "to string" methods and narrative error reporting that provides all
> the info you need.
>

Something like that. Definitely.

> Whenever I describe unit testing to people, I tell'em that unit
> testing is what you have always done.
>
> You have always written a chunk of code, and then written something to
> exercise it, and print the results out on the screen. You then eyeball
> the results and say, Yip! That was OK. (or not).
>
> The difference is with unit testing is I'm asking you to record that
> oracle, that knowledge, that expertise you have of whether a result is
> "right" or not, as a program that others can run.
>

From a TDD perspective either of those are backwards. The idea is that
I tell the machine what I want the code to do and I ask it to tell me
when it does (or doesn't) do it.

> The small tweak to agile I'm suggesting now comes down to this...
>
> If the test/assert/error were to fail/trigger/occur, what would we get
> the debugger to print out, to understand the bug. And just encode that
> knowledge, that expertise you have so the information is there on the
> screen, the error report, the log trace when the test fails.
>

Not a new idea. It's been written about and discussed many times here
and elsewhere. It is canonical to TDD. But, I'm glad you discovered it
too! :-)

BTW, it's sometimes even better to know that you don't need any
additional information, because the given test can only fail for one
reason and you know precisely what that reason is.

Always an optimist. I love that.

Whenever someone says to me, "The way you described turned out to be
sub-optimal. So I modified it." And then in the course of discussion
they say things that make me suspect it is possible that they hadn't
fully understood or adopted my suggestions, I am concerned that the
adaptations are not local optimizations but simply a substitution for
missing skills/knowledge needed to do it the way that was suggested.

If that is the case it is okay. However, we are also talking about
academic research (And, as Steven pointed out PhD level research is
supposed to be on the cutting edge - moving the state of knowledge
forward.) I think that it is even more important in an academic
context to fully grok a concept before you attempt to change it.

I'm also a little weary of what direction "forward" is in this
context. Creating something more RUP-like is not "forward" in my
humble opinion. I worked for a guy who claimed to be doing a blend of
Scrum and RUP, but what he was really doing was failing to understand
Scrum at all and just doing an iterative sort of RUP (WIth daily
meetings where we had to listen to him talk for half-an-hour.) That's
fine, until you start selling it to others as some sort of "improved
Scrum" when you've yet to actually try what Scrum suggests.

On Sun, Jul 5, 2009 at 10:03 PM, kentb<kentb@...> wrote:
>
>
> Dear Zaidoun,
>
> It sounds like you made a sensible local adaptation of XP for your
> situation. That's what XPers do. The question of whether those adaptations
> are more generally applicable is worth careful study. Please keep me
> apprised of your progress.
>
> Regards,
>
> Kent Beck
> Three Rivers Institute
>
> _____
>
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of zaidoun alzoabi
> Sent: Friday, July 03, 2009 8:49 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [good] [XP] Preparing XP for the big projects
>
> Dear all,
> thanks for your reply
>
> your questions could be answered through reading this article
> www.ieeexplore.ieee.org/iel5/4520396/4529902/04530347.pdf
>
> but for te time I will answer your main questions;
>
>
> We have used XP in a big project that intended to computerize the tax
> autority processes in Syria. The system is considered very complex due to
> the many laws, regulations, decrees, and procedures used.
> we had to modify the lifecycle of XP in order to deal with the complexity of
> the system, this happened through adding a clear analysis phase before any
> release, and breaking the system into smaller modules each taken by pair
> developers.
> in the analysis phase we used formal meeting sessions with tax experts and
> managers and we used DFD and ERD to communicate with them.
> These people did not have time to communicate with us on frequent basis and
> in many cases they had conflicting ideas, this why we needed formal
> communication with them.
> pair development is different from pair programming as the pair here will
> not only sit at the same computer and do the coding, our pair will do the
> analysis for their module, desing the solution, integrate with the design of
> other pairs modules and then do the coding
> development=analysis+desing+programming+testing
> the research goes beyond Boehm and Turner "balancing Agility with
> Discipline" by saying how to do that in reality, and that too by focusing on
> Nonake spiral knowledge sharing model SECI
> best regards
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>

But IMO, your need for debugging goes down drastically for a code that is
developed with unit tests, may be the log messages that you write are the ones
that you need to verify with a unit test. That way you don't need to manually
inspect the errors, but the failing Unit Tests give you an immediate feedback!

Jayadeep

--- In extremeprogramming@yahoogroups.com, John Carter <john.carter@...> wrote:
>
> Here's a thought for ye Agile folk.
>
> We've had YAGNI, You're Ain't Gonna Need It, as a tool to reduce the
> weight of code that slows our ability to change, to be agile.
>
> Here's another.
>
> YAGDI You Are Gonna Debug It.
>
> You may be perfectly Test Driven, you may have a perfect suite of unit
> tests...
>
> But if all those tests give you is "it failed", the first thing you
> are going to do is scrabble around for more information.
>
> So design your code, write your tests to expose enough information,
> write KNOWING YOU WILL BE DEBUGGING THIS CODE.
>
> 'Cause the simple fact is you will be debugging that code. Probably
> now, maybe next year, and certainly if, being agile, you ever change
> it.
>
> Often I merely need to look at either my log trace or my unit test
> output and I know what the fault is.
>
> My next step is to add an assertion either in the test, or the code
> that will prove that I know what the bug is.
>
> Then I fix it.
>
> If I can't immediately tell where the bug is, I alter the design to
> expose in the error messages, the log traces, the reports, the reasons
> it behaved as it did.
>
> Think of it as a story, a narrative. The person who cares should be
> able to read the narrative of the systems behaviour.
>
> The user who doesn't care, should just be told which log file to email
> to support.
>
>
>
> John Carter
>

On Sun, Jul 5, 2009 at 8:02 PM, p_jayadeep<p_jayadeep@...> wrote:
>
>
> But IMO, your need for debugging goes down drastically for a code that is
> developed with unit tests, may be the log messages that you write are the
> ones that you need to verify with a unit test. That way you don't need to
> manually inspect the errors, but the failing Unit Tests give you an
> immediate feedback!
>

I think that is what he is saying. He's saying that a test failure
should provide the same information that a log (or a debugger) would
provide. But, if you are saying that the tests should be responsible
for asserting the state rather than the objects being responsible for
informing on it, then I share your same concern with what is being
suggested.

John Carter wrote:

> You may be perfectly Test Driven, you may have a perfect suite of unit
> tests...
>
> But if all those tests give you is "it failed", the first thing you
> are going to do is scrabble around for more information.

All assertions should report everything they know - the equivalent of a complete
debugging environment, with stack traces and variable values - when they fail.

But the first thing you should do when tests fail is revert the code until they
pass. Boom - no debugging.

--
    Phlip

John,

> The small tweak to agile I'm suggesting now comes down to this...
>
> If the test/assert/error were to fail/trigger/occur, what would we get
> the debugger to print out, to understand the bug. And just encode that
> knowledge, that expertise you have so the information is there on the
> screen, the error report, the log trace when the test fails.

I'm not sure I understand what you are proposing. Perhaps an example would help.

Also: how is this a "tweak to agile"?

Puzzled, Ilja

Ilja Preuß wrote:
> John,
>
>> The small tweak to agile I'm suggesting now comes down to this...
>>
>> If the test/assert/error were to fail/trigger/occur, what would we get
>> the debugger to print out, to understand the bug. And just encode that
>> knowledge, that expertise you have so the information is there on the
>> screen, the error report, the log trace when the test fails.
>
> I'm not sure I understand what you are proposing. Perhaps an example would
help.

Maybe, for a start, when an assert as simple as this fails...

    assert foo == 42

..it should print out the name 'foo', its value, and the source expression, "foo
== 42".

--
    Phlip

So a friend drops me an email out of the blue and asks:
>
> Now onto the work bit.. You have in the past developed using agile
> development techniques. I was curious as to how you previously handled
> determining the progress of projects. Currently we use two pieces of
> effort, a 15 min granularity spreadsheet so we can see where time is
> being used up, and a log time remaining system, so you can see specific
> progress on larger items of work. This system doesn't work particularly
> well and we are looking at alternative setups. I was wondering if you
> had any experience / advice? :) Probably been a while for you :)
>

Since I had a train journey and nothing better to do, I wrote a reply:
http://Stua.rtS.co.tt/DeterminingProjectProgress.pdf

Having no doubt confused him, but hopefully got the brain whirring
into action, does anybody know of up-to-date articles written by
experts that I could point him at?

ta,
~Stuart