eXtreme programming vs. software product lines

Last w I attended a talk describing Product Line Systems, which I
found rather interesting. Something about it seemed right.

Of course, XP seems right as well.

What I haven't quite gotten my head around is whether the two ideas
(YAGNI vs. `intentionally factor out what you can reuse and write it so
you can') are intrinsically in opposition or merely orthogonal
(operating at different levels).

Any input would be appreciated.

Many thanks,
--ag
--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays

Artie Gold wrote:

> Last w I attended a talk describing Product Line Systems, which I
> found rather interesting. Something about it seemed right.
>
> Of course, XP seems right as well.


The SEI thought leaders for PLS, Paul Clements and Linda Northrop, profess
their scheme is agnostic with regards to your religion. That means they
don't require Big Requirements or Design Up Front.

> What I haven't quite gotten my head around is whether the two ideas
> (YAGNI vs. `intentionally factor out what you can reuse and write it so
> you can') are intrinsically in opposition or merely orthogonal
> (operating at different levels).

Who's your customer?

SPL is a star topology, where a core project invests in things that change
slowly, and volatile planetary products re-use, extend, and configure the
core.

SPL presents the optional ideal that one team runs the core project, and
planetary teams work the products.

Whether you follow that or not, if you have a star topology then the planet
products are all customers of the core.

Customers like clearly defined interfaces that change slowly. Hence, the
core project has an overriding user story "define and productize interfaces
so clear and useful that new products are as easy as assembling a kit". This
story overrides YAGNI because a customer asked for it.

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

On Tue, 15 Feb 2005 22:45:06 -0600, Artie Gold
<artiegold@austin.rr.com> wrote:

>
>What I haven't quite gotten my head around is whether the two ideas
>(YAGNI vs. `intentionally factor out what you can reuse and write it so
>you can') are intrinsically in opposition or merely orthogonal
>(operating at different levels).

If one were following YAGNI, one might still factor things out and
write them so they can be reused if:

1. There was more than one occurrence of similar code. Duplication
must be removed. This tends to create code which is not only
potentially reusable, but actually reused!

2. The code does not express the programmer's ideas well. Code must be
expressive. This tends to create methods ... and to evolve to classes
... that do useful t hings, just because we felt the need to express
the idea.

So if I were not creating a library, but an application, I would do
the two things above all the time. I find that that often creates
reusable stuff right about when I need it. If it doesn't, then when I
need it is a good time to do the refactoring, according to the YAGNI
notion.

If I was building a library for export, then the library is
intentionally reusable, and its API is much of its requirements. In
that case, the usability and reusability are driven by the stories.
Refactoring to remove duplication and express ideas still holds, of
course.

Does that help relate the two a bit? If not, please inquire further.

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 15 Feb 2005 22:45:06 -0600, Artie Gold
<artiegold@austin.rr.com> wrote:

>Last w I attended a talk describing Product Line Systems, which I
>found rather interesting. Something about it seemed right.
>
>Of course, XP seems right as well.
>
>What I haven't quite gotten my head around is whether the two ideas
>(YAGNI vs. `intentionally factor out what you can reuse and write it so
>you can') are intrinsically in opposition or merely orthogonal
>(operating at different levels).

A third option is that YAGNI+TDD is a way to achieve "intentionally
factor out what you can reuse and write it so you can".

We started working on FitNesse two years ago.  We decided to follow
the rules of XP as closely as possible.  We have assiduously applied
TDD and YAGNI at every stage of the development.

FitNesse is a wiki.  It stores pages on disk.  The simplest way for us
to do this was to use flat files, and to store each page as it's own
file.

Our unit tests were written first.  In order to test the code that
processes pages, we had to have a page source.  The simplest page
source we could think of was one that held all the test pages in RAM.
So we created an interface for the tests, and the rest of the
application to use.  For some tests this interface was implemented
trivially as a MockPage.  For other tests it was implemented as a
simple in-RAM storage mechanism.  It was months before we finally had
to create an implementation that actually stored the pages on disk.

A year later, Steve, one of the users of FitNesse decided that flat
files were insufficient for his purposes.  He wanted all the pages
held in a relational database.

This is the "nightmare" scenario.  This is the situation that many
architects fear will happen when YAGNI is applied.  The software was
created with one set of assumptions, and now an obvious new
requirement completely contradicts all those assumptions.

It took Steve a day or two to write the back end for FitNesse to use a
relational database.  It turned out that all the TDD and YAGNI we had
been doing had put the code in just the right form for him to reuse
the application in a database environment.
-----
Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

Robert C. Martin wrote:

> It took Steve a day or two to write the back end for FitNesse to use a
> relational database.  It turned out that all the TDD and YAGNI we had
> been doing had put the code in just the right form for him to reuse
> the application in a database environment.

Steve, this is Mark. Mark wants to store the Wiki pages inside little wooden
ships inside bottles.

Mark has never used this Wiki before, has no pre-existing pages, and has no
clue about the Wiki's architecture.

Making Mark's job even easier than Steve's is what SPL's productization
phase is all about.

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

Ron Jeffries wrote:
> On Tue, 15 Feb 2005 22:45:06 -0600, Artie Gold
> <artiegold@austin.rr.com> wrote:
>
> 
>
>
> If one were following YAGNI, one might still factor things out and
> write them so they can be reused if:
>
> 1. There was more than one occurrence of similar code. Duplication
> must be removed. This tends to create code which is not only
> potentially reusable, but actually reused!
>
> 2. The code does not express the programmer's ideas well. Code must be
> expressive. This tends to create methods ... and to evolve to classes
> ... that do useful t hings, just because we felt the need to express
> the idea.
>
> So if I were not creating a library, but an application, I would do
> the two things above all the time. I find that that often creates
> reusable stuff right about when I need it. If it doesn't, then when I
> need it is a good time to do the refactoring, according to the YAGNI
> notion.
>
> If I was building a library for export, then the library is
> intentionally reusable, and its API is much of its requirements. In
> that case, the usability and reusability are driven by the stories.
> Refactoring to remove duplication and express ideas still holds, of
> course.
>
> Does that help relate the two a bit? If not, please inquire further.
>
It does.

Back a couple of decades ago (well, just a little more than that, but
who's counting) our approach was something along the lines of (using a
food analogy):

Break the problem into `meal-sized' chunks.

Figure out the overall menu.

As you do this, ferret out the individual ingredients -- in as generic a
way as possible.

Start cooking (write high level code).

Prepare the individual ingredients.

Oh dear, I'm getting way behind; I've got to tie this all up (with the
mid level code).

Oh wait! I'm done. And the next one will be easier!

We used to (semi-jokingly) call it `outside-in programming'. It ain't
rocket surgery.

Thanks again,
--ag

BTW - how does someone who understands this stuff get back into the game
when so many people seem to want to make the process more complicated
than it needs to be? [A trend to which I see XP as being a vital reaction.]

--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
 news:8979111lrdv47mes6iv58fc90h4fscjosb@
4ax.com...
> On Tue, 15 Feb 2005 22:45:06 -0600, Artie Gold
> <artiegold@austin.rr.com> wrote:
> 
>
> A third option is that YAGNI+TDD is a way to achieve "intentionally
> factor out what you can reuse and write it so you can".
>
> We started working on FitNesse two years ago.  We decided to follow
> the rules of XP as closely as possible.  We have assiduously applied
> TDD and YAGNI at every stage of the development.
>
> FitNesse is a wiki.  It stores pages on disk.  The simplest way for us
> to do this was to use flat files, and to store each page as it's own
> file.
>
> Our unit tests were written first.  In order to test the code that
> processes pages, we had to have a page source.  The simplest page
> source we could think of was one that held all the test pages in RAM.
> So we created an interface for the tests, and the rest of the
> application to use.  For some tests this interface was implemented
> trivially as a MockPage.  For other tests it was implemented as a
> simple in-RAM storage mechanism.  It was months before we finally had
> to create an implementation that actually stored the pages on disk.
>
> A year later, Steve, one of the users of FitNesse decided that flat
> files were insufficient for his purposes.  He wanted all the pages
> held in a relational database.
>
> This is the "nightmare" scenario.  This is the situation that many
> architects fear will happen when YAGNI is applied.  The software was
> created with one set of assumptions, and now an obvious new
> requirement completely contradicts all those assumptions.
>
> It took Steve a day or two to write the back end for FitNesse to use a
> relational database.  It turned out that all the TDD and YAGNI we had
> been doing had put the code in just the right form for him to reuse
> the application in a database environment.

And the driver for that is that you already had two different
implementations. It's the second implementation that's the
killer. In comparison, adding a third is relatively easy, and
adding a fourth is even easier.

John Roth


> -----
> Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com
> Object Mentor Inc.            | blog:  www.butunclebob.com
> The Agile Transition Experts  | web:   www.objectmentor.com
> 800-338-6716
>
>
> "The aim of science is not to open the door to infinite wisdom,
> but to set a limit to infinite error."
>    -- Bertolt Brecht, Life of Galileo