Jobs Available: Extreme Programming Digest Number 8683

Messages

1a.

Re: 8 Things you Can do to improve your software

Posted by: "Daniel Pupek" dan@agilejedi.com danielpupek

Thu May 8, 2008 3:25 am (PDT)

A list I go back and update infrequently is my lessons learned
list<http://blog.agilejedi.com/2006/12/mmmm.html>.
Don't let the publish date fool you I have updated it more recently.

On a side note...I've been reading Manage
It!<http://pragprog.com/titles/jrpm/manage-it>and so far I am fairly
impressed. It ties together some sound advice and
provides a realworld reference. Johanna touches on very broad spectrum of
topics while maintaining a conversational tone. It's not the end all for PM
books but it does serve as a great playbook for those of us in the Agile
world.

Dan

On Wed, May 7, 2008 at 4:46 PM, Osias Jota <osias.ig@ig.com.br> wrote:

> Relax, man, I liked that line, and I'm not against that kind of list.
> Acutally, I enjoy most of them, do you have others for me to read?
>
> On 4/10/08, Daniel Pupek <dan@agilejedi.com <dan%40agilejedi.com>> wrote:
> >
> > Wow....very constructive. You're a genius.
> >
> > Dan
> >
>
> [Non-text portions of this message have been removed]
>
>
>

Checkout my blog @ http://blog.agilejedi.com
Checkout my homepage @ http://www.agilejedi.com

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

Re: YAGNI Football Analogy

Posted by: "Brandon Byars" brandon.byars@gmail.com brandon.byars

Thu May 8, 2008 4:32 am (PDT)

Hi J.B.,

> > Why is deploying a new web service expensive? Is it disruption to
> > others, or is the actual process to deploy the web service not
> > completely automated?
>
> Because deploying the web service takes more time than not deploying the
> web service.

Or, as in the case of the project I'm currently on, because a
non-agile team is building the web service that we depend on. Asking
for extra data up front makes some sense, thinks me.
--
Brandon Byars
http://brandonbyars.com

Re: YAGNI Football Analogy

Posted by: "Matt" maswaffer@gmail.com maswaffer

Thu May 8, 2008 7:15 am (PDT)

Marty,

--- In extremeprogramming@yahoogroups.com, "marty.nelson"
<noslenytram@...> wrote:
>
> --- In extremeprogramming@yahoogroups.com, "Matt" maswaffer@ wrote:
> > Makes sense. Viewed that way, the entire SomeInformation class
should
> > be marshalled with every call whether the client needs the entire
> class
> > or not. Is this what you are getting at?
>
> Not necessarily. It only need contain what was requested.
>
> Let's consider that, hypothetically:
>
> Name GetName(int id) //x
> Address GetAddress(int id) //y
>
> What I'm suggesting is that let's say we know our user wants to get
> some customer information, so:
>
> Customer GetCustomer(CustomerRequest request)

This is close to what we have... except we aren't in an environment
(yet) that handles strongly typed return types over web services. So it
is more like:

string GetCustomer([args that uniquely identify a customer])

Where the string is an xml representation of a Customer object. Not
ideal but it's what we have for now.

>
> for x, the only thing we need to do is:
>
> CustomerRequest.Id
> Customer.Name

Ok...

>
> which leaves us in a good position for y adding:
>
> Customer.Address
> CustomerRequest.ReturnName = true
> CustomerRequest.ReturnAddress = true
> //or if you prefer:
> CustomerRequrest.DataScope = DataScope.Name | DataScope.Address

So I am still a little unclear about what "adding" means to you. In our
scenario, on the server side, all of these fields already exist for
other functionality that is already in place. So our Customer already
has Address, ReturnName, ReturnAddress etc. Now we are leveraging this
information on a different client... one that accesses the Customer via
a web service.

So to me, "adding" means "adding Address and ReturnName to the xml that
is returned" not "adding Address and ReturnName to the Customer".

>
> And we're probably in good shape for z, q, and t as well.
>

So, is it a violation (in your opinion) of YAGNI to write the code to
convert *all* of the Customer class to xml the first time I needed *any*
of the Customer class on the client side?

To me, it "felt" like it was when I did it... but as Ron pointed out a
few weeks ago on this list... my "feelings" on YAGNI aren't entirely
correct... which is why I am asking others' opinions! :)

Matt

Re: YAGNI Football Analogy

Posted by: "marty.nelson" noslenytram@yahoo.com marty.nelson

Thu May 8, 2008 12:29 pm (PDT)

--- In extremeprogramming@yahoogroups.com, "Matt" <maswaffer@...>
wrote:
>
>
> Marty,
>
>
> --- In extremeprogramming@yahoogroups.com, "marty.nelson"
> <noslenytram@> wrote:
> >
> > --- In extremeprogramming@yahoogroups.com, "Matt" maswaffer@
wrote:
> > > Makes sense. Viewed that way, the entire SomeInformation class
> should
> > > be marshalled with every call whether the client needs the
entire
> > class
> > > or not. Is this what you are getting at?
> >
> > Not necessarily. It only need contain what was requested.
> >
> > Let's consider that, hypothetically:
> >
> > Name GetName(int id) //x
> > Address GetAddress(int id) //y
> >
> > What I'm suggesting is that let's say we know our user wants to
get
> > some customer information, so:
> >
> > Customer GetCustomer(CustomerRequest request)
>
>
> This is close to what we have... except we aren't in an environment
> (yet) that handles strongly typed return types over web services.
So it
> is more like:
>
> string GetCustomer([args that uniquely identify a customer])
>
> Where the string is an xml representation of a Customer object. Not
> ideal but it's what we have for now.

Well even if the platform does have built in stuff, it's being
reduced to that anyway. Do you some type of Service Agent or Adapter
buffering the serivce on the client side (that's repackaging the xml
into objects)? If so, you can do whatever you want on the web
service call. Building very specific wire-level service calls is a
change nightmare.

> > which leaves us in a good position for y adding:
> >
> > Customer.Address
> > CustomerRequest.ReturnName = true
> > CustomerRequest.ReturnAddress = true
> > //or if you prefer:
> > CustomerRequrest.DataScope = DataScope.Name | DataScope.Address
>
>
> So I am still a little unclear about what "adding" means to you.
In our
> scenario, on the server side, all of these fields already exist for
> other functionality that is already in place. So our Customer
already
> has Address, ReturnName, ReturnAddress etc. Now we are leveraging
this
> information on a different client... one that accesses the Customer
via
> a web service.
>
> So to me, "adding" means "adding Address and ReturnName to the xml
that
> is returned" not "adding Address and ReturnName to the Customer".

yes, that sounds right.

> >
> > And we're probably in good shape for z, q, and t as well.
> >
>
>
> So, is it a violation (in your opinion) of YAGNI to write the code
to
> convert *all* of the Customer class to xml the first time I needed
*any*
> of the Customer class on the client side?

Qualified yes. Let's say this new app only needed Name, I don't lose
anything by not doing the serialization for Address, etc. I don't
lose anything by doing Name this week, and Address next week. In any
case, release 1 the xml has Name, release 2 the xml has Name and
Adresss. This is what I mean by adding.

Now by all means, if the stories are too small, then advocate for a
single serialize Customer to xml story.

> To me, it "felt" like it was when I did it... but as Ron pointed
out a
> few weeks ago on this list... my "feelings" on YAGNI aren't entirely
> correct... which is why I am asking others' opinions! :)
>
> Matt
>

Re: Unit Testing Question [ some explanations & a better example]

Posted by: "Gary Brown" glbrown@inebraska.com gb70840

Thu May 8, 2008 4:55 am (PDT)

Hi, Steve,

----- Original Message -----
From: "Steven Gordon" <sgordonphd@gmail.com>
To: <extremeprogramming@yahoogroups.com>
Sent: Wednesday, May 07, 2008 8:10 PM
Subject: Re: [XP] Re: Unit Testing Question [ some explanations & a better
example]

> Gary,
>
> I would generally recommend The book Fit for Developing Software:
> Framework for Integrated Tests by
> Muckridge and Cunningham. The standard approach is to "test below the
> GUI" to create executable specifications of the business rules that
> are independent of presentation and workflow. This tends to promote a
> more flexible architecture that will allow the GUI to evolve
> independently from the generally more stable business rules
> implementation. Sometimes, it can be a challenge when the customer
> sees the GUI as the application.

I agree with all of the above.

>
> Perhaps I can provide more specific help if you can tell me more about
> the following:
> - What made this approach successful for your data conversion project?
> - How are the projects different?
> - What specific problems are you encountering when you try to do the
> same thing for your web project?

The data conversion process is the same thing over and over. Read the input
file, convert to our format, clean it up, write the output file. We had a
stable text document used to describe the requirements. We pulled it into
Fitnesse, added test cases, and presto, instant executable specification.
They are a bit verbose for my tastes, but they seem to work pretty well.

The other projects are a wide variety of web applications. We insist on
testing through the GUI. The available tools are slow and klunky. The
customers don't like the underlying table formats.

GB.

Re: Unit Testing Question [ some explanations & a better example]

Posted by: "Jonathan Rasmusson" rasmus4200@yahoo.com rasmus4200

Thu May 8, 2008 3:17 pm (PDT)

Have you seen or tried Selenium?

http://selenium.openqa.org/

I am using it an find it quite good for high level smoke tests through
web applications.

It has a separate recorder plug-in (for Firefox) - so no programming.

Cheers - Jonathan

--- In extremeprogramming@yahoogroups.com, "Gary Brown" <glbrown@...>
wrote:
>
> Hi, Steve,
>
> ----- Original Message -----
> From: "Steven Gordon" <sgordonphd@...>
> To: <extremeprogramming@yahoogroups.com>
> Sent: Wednesday, May 07, 2008 8:10 PM
> Subject: Re: [XP] Re: Unit Testing Question [ some explanations & a
better
> example]
>
>
> > Gary,
> >
> > I would generally recommend The book Fit for Developing Software:
> > Framework for Integrated Tests by
> > Muckridge and Cunningham. The standard approach is to "test below the
> > GUI" to create executable specifications of the business rules that
> > are independent of presentation and workflow. This tends to promote a
> > more flexible architecture that will allow the GUI to evolve
> > independently from the generally more stable business rules
> > implementation. Sometimes, it can be a challenge when the customer
> > sees the GUI as the application.
>
> I agree with all of the above.
>
> >
> > Perhaps I can provide more specific help if you can tell me more about
> > the following:
> > - What made this approach successful for your data conversion project?
> > - How are the projects different?
> > - What specific problems are you encountering when you try to do the
> > same thing for your web project?
>
> The data conversion process is the same thing over and over. Read
the input
> file, convert to our format, clean it up, write the output file. We
had a
> stable text document used to describe the requirements. We pulled
it into
> Fitnesse, added test cases, and presto, instant executable
specification.
> They are a bit verbose for my tastes, but they seem to work pretty well.
>
> The other projects are a wide variety of web applications. We
insist on
> testing through the GUI. The available tools are slow and klunky. The
> customers don't like the underlying table formats.
>
> GB.
>

Unit Testing Queries and Stored Procedures

Posted by: "Christopher K. Joiner, Jr." ckjoinerjr@gmail.com ckjoinerjr

Thu May 8, 2008 5:24 am (PDT)

During our last Reflections, this week, we have discovered that when our
code is mostly table driven and requires mostly queries or stored procedures
to accomplish the task, we tend to write less red lights than normal. We
will tend to write a light to ensure that the query will actually pull back
records that we put in the table during SetUp. We are at a loss as to what
else needs to be tested, if anything. It makes a lot more sense when we are
testing functions that involve logic because every decision that code can
make needs at least one light plus the extreme cases, etc. But we can not
fully figure out how to apply this to queries. Does anyone have similar
experiences and/or does anyone have any pointers on how to create a more
substantial, more extensive Unit Test coverage in those situations?
*
*--
.Chris.

Christopher K. Joiner, Jr.
Senior Agile Software Developer
XP Coach
PrimeTel Communications, Inc.

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

Re: Unit Testing Queries and Stored Procedures

Posted by: "Kent Beck" kentb@earthlink.net kentlbeck

Thu May 8, 2008 11:12 am (PDT)

Dear Chris,

I'm afraid I don't have the experience to provide a simple recipe. However,
I can tell you how I think I'd approach your problem.

It seems like you have a case where the vanilla practices don't fit. For me,
when the practices don't fit, I go back to principles. In this case, the
first question I would ask is whether you are having any problems with the
area of the system in question. If not, you may already be done. However,
assuming that the code is a source of errors, one basic principle I use is
to double-check error-prone decisions. This has both short- and long-term
costs, because of the extra work involved now and in keeping the two
representations synchronized. However, this is generally worth it as long as
the system doesn't change too fast. Assuming you want to double-check, I'd
apply the principle of reflection to look at what kind of errors are most
common and find a way to double-check for those.

Does this help?

Regards,

Kent Beck
Three Rivers Institute

_____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Christopher K.
Joiner, Jr.
Sent: Thursday, May 08, 2008 5:25 AM
To: extremeprogramming@yahoogroups.com
Subject: [XP] Unit Testing Queries and Stored Procedures

Christopher K. Joiner, Jr.
Senior Agile Software Developer
XP Coach
PrimeTel Communications, Inc.

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

Re: Unit Testing Queries and Stored Procedures

Posted by: "max@hexsw.com" max@hexsw.com maxguernseyiii

Thu May 8, 2008 11:53 am (PDT)

It's not unlike class development: you have a thing (e.g.: a table)
that does something (stores data) that can only be used under certain
circumstances (constraints). So you test that the thing does what it
should do by ensuring it stores data as you've already said. Then you
test that it protects itself from invalid requests (testing for
constraints). It's pretty much the same process for stored procedures.
Like Kent said, go back to principles.

(Soap box time:)

I find, though, that testing what the database does is only half the
story. Those tests are meaningless unless you have confidence that the
production databases will be like your test database. To gain that
confidence, you also have to test how your databases are built.

-- Max

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

From: "Christopher K. Joiner, Jr." <ckjoinerjr@gmail.com>
Sent: Thursday, May 08, 2008 12:25 AM
To: extremeprogramming@yahoogroups.com
Subject: [XP] Unit Testing Queries and Stored Procedures

Christopher K. Joiner, Jr.
Senior Agile Software Developer
XP Coach
PrimeTel Communications, Inc.

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

Re: Success rates of Agile Transitions

Posted by: "Niraj Khanna" niraj@diasparsoftware.com nkhanna_01

Thu May 8, 2008 10:56 am (PDT)

Hi Unmesh,

Sorry for not responding in over 1 month. We were away on vacation.
> So to measure success or failure of "Agile" transition is to measure
> if people are thinking for themselves, rather than blindly following
> agile coach's advice and running behind agile buzzword. How can we
> measure that?
>

I think what you're describing maybe a symptom or practice of why some
agile transitions "succeed" over others that "fail". I'm just
interested in measuring whether it succeeds or fails. A secondary and
more useful study would be "why do agile transitions succeed/fail".
Finally, to be quite honest, I wouldn't be surprised to see "Blindly
following agile manual" in either the "success" or "failure" camp. I
think Ron has discussed practicing all the XP practices before
deciding which ones to drop, but I can also see how practicing and
applying practices without an understanding of expected benefits
coulod lead to adoption failure.

Thanks,
Niraj.

Re: Executable Specifications

Posted by: "Craig Davidson" craigmdavidson@gmail.com craigdavidson2007

Thu May 8, 2008 12:01 pm (PDT)

Hi Gary,

Customers see the system as the user interface, because for them the user
interface IS the system. It's a fact that we can choose either to fight or
embrace.

After struggling with customer testing web apps with Fit for years.
My customers didn't like the tests. Actually, to be honest - I didn't like
the tests.
I'd decided I was trying fit a square peg into a round hole.

Since then I've had some great experiences combining Watir and RSpec.
I've got a few posts on this:
my rationale for this...
http://www.agileadvisor.com/2007/12/keeping-customer-tests-interesting.html
and more detail (with some sample tests):
http://www.agileadvisor.com/2008/01/customer-testing-with-ruby-watir-rspec.html

But in short..
What's good about the approach?
----
*It produces simple easy to read tests.
*Your scripting language is a first class language. I rely heavily on some
standard oo patterns to get the tests into the format I want - an executable
specification.
*The first class language allows almost all the "usual suspects" causing
brittleness with via the GUI testing can be controlled with a few patterns.
*You can test any web app in any language.
*You can run the same tests against the integration server, the system test
server or the production server. As long as your test code is DRY you can
parameterise the system under test.
*You get really nicely formatted test reports.
And most importantly:
*The customers see the "actual" system working.

What's bad about the approach?
----
*Relatively slow running tests. But we are dealing with customer tests not
developer tests.
*Watir only works with Internet Explorer (although FireWatir, and others
exist).
*You are writing stylised Ruby code, so the actual test script needs to be
written by a programmer.
*It is more suited to flow based functionality (we do this, then this, then
that) than complex business logic (where I think Fit is great). However, for
most web apps I've build and seen they are more flow based than complex
business logic.

In the main I think the good outways the bad.

Any questions around this give me a shout.

Cheers,

Craig

On 08/05/2008, Gary Brown <glbrown@inebraska.com> wrote:
>
> We've done it with our data conversion process. We'd like to do it with
> our web apps. Anyone have that experience?
>
> GB.
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------------------
>
> 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
>
>
>
>

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

Re: Executable Specifications

Posted by: "Cory Foy" usergroup@cornetdesign.com cory_foy

Thu May 8, 2008 6:59 pm (PDT)

What have you tried? What has or hasn't worked?

Cory

-----Original Message-----
From: "Gary Brown" <glbrown@inebraska.com>
To: extremeprogramming@yahoogroups.com
Sent: 5/7/08 8:33 PM
Subject: [XP] Executable Specifications

We've done it with our data conversion process. We'd like to do it
with our web apps. Anyone have that experience?

GB.

[