Re: [XP] meaning of "could possibly work" clause

... Philps set of Simplest ways of making a test pass then refactoring the simple code into well designed code are great, I ve used the same kind of set for

Message 1 of 22
, Jun 1, 2006

0 Attachment

Paul Campbell wrote:

> Heres a question for the house: what does "simplest thing that could
> possibly work" mean over and above just "simplest thing" ?. All it
> seems to do is exclude things which dont work, and what is the point
> of that in a TDD world ?.
>
> But worse than merely being tuatologous, to me it encourages
> missinterpretation of "simple" as easiest/quickest/most expedient and
> thus is not a phrase I would ever use myself to convey what I mean by
> "simplest".
>
> Paul.
>
>

Philps set of 'Simplest ways of making a test pass then refactoring the
simple code into well designed code' are great, I've used the same kind
of set for a number of years now and i would encourage anyone new to TDD
to use them.

That said, I think its worth adding what for me 'Simplest thing...' does
NOT mean.

It does NOT mean being lazy or ignoring the techniques, designs,
pit-falls we have already learned.

Yet this is often the first thing I see people doing in the name of
DTSTTCPW.

One example i saw the other year was when a pair decided that creating a
Singleton was the 'Simplest thing...'. Sure it was a simple solution to
their problem. It allowed them to quickly speed through the story, as
they didn't need to modify the current design, they could simply invoke
the getInstance() method wherever and whenever they liked - great!

Errr no, not really, it created the start of a mess, because an up
coming iteration required that we'd need to create two instances of the
class.

Whilst working on this later iteration, one of the original pair was
also working on the story which required us to create a second instance
of the class. Again, the 'Simplest thing...' misconception kicked in
with them. They didn't look at the current singleton design and think
'Hmm we should refactor this singleton away'. No, they 'Simply' added a
setInstance() method to the Singleton.

So now we had a singleton that actually wasn't a singleton - all because
of they'd taken the 'Simplest thing...' too literally.

They even joked that they'd '..had to create a Doubleton' - its humor
was lost on the delay it caused when we had to change the design.

I'd agreed whole heartedly therefore that Simplest can often be mistaken
(whether deliberately or not) as easiest/quickest/most expedient.

Andrew

Walter Prins

Hello Andew, Yes. To me the work part of could possibly works implies that you need to take a brief step back and ensure that whatever you come up with

Message 2 of 22
, Jun 1, 2006

0 Attachment

Hello Andew,

Yes. To me the "work" part of "could possibly works" implies that you
need to take a brief step back and ensure that whatever you come up with
must be able to at least satisfy not just the immediate need (that is,
to get to green for this story), but you must at least be able to also
foresee some simple-ish path forward for the other bits you're aware
that will happen or will be needed (as imperfect and incomplete as that
understanding might be at that moment.) At the very least, whatever
you do now in the name of simplicity must not obviously cause complexity
and trouble come the next story.

So, considering your Singleton example: for this reason, I would
probably have rejected the whole idea of using a singleton there as I
would've seen that it probably would not work (or, at least, not in a
simple manner) when we got to some of the other stories that were in the
pipeline.

It seems to me that interpreting TSTTCPW in this way thus helps avoid (I
hope/I think) the oversimplistic thinking that you refer to. Thoughts?

I discovered XP about a year and a half ago and have been migrating my thinking in that direction since then so I m by no means an expert. I have to confess

Message 3 of 22
, Jun 8, 2006

0 Attachment

I discovered XP about a year and a half ago and have been migrating my
thinking in that direction since then so I'm by no means an expert. I have
to confess that I did initially take the simplest thing to mean the easiest
thing.

I'll go back to Kent's list in light of Andrew's issue.
1. Runs all the tests - The Singleton obviously ran all tests, so did the
Doubleton.
2. Contains no duplication - Guessing they both still pass this test as
well.
3. Expresses all the code's design ideas - The Singleton totally could have
done this but I don't know what the code actually looked like. However, the
Doubleton breaks down here. It sounds like it doesn't do a great job of
making the design clear.
4. Minimizes entities (classes, methods, ...) - Yeah, sounds like they both
achieve this.

The question in my mind now is:
Does the simplest design state that you should take into account stories to
come when constructing your design for the story right now?

If down the road you'll need a plane, but this story only wants something
that'll drive down the runway, should you construct landing gear and some
fuselage or just a build a moped?

"Right" kindof depends on how things turn out. If you end up constructing a
plane as was planned, you'll be pleased. Your extra effort to construct
landing gear and fuselage was worth it. However, if all you ever need is
something that'll drive down a runway, or if your planned "flying" stories
are scraped and replaced with "drive down the road" stories, you'll have
wasted time. And until you implement the flying stories you have this weird
plane shaped vehicle teetering around. Wasn't one of the goals of XP to
always have an ideal system at the end of an iteration?

Anthony

On 6/1/06, Walter Prins <wprins@...> wrote:
>
> Hello Andew,
>
> Yes. To me the "work" part of "could possibly works" implies that you
> need to take a brief step back and ensure that whatever you come up with
> must be able to at least satisfy not just the immediate need (that is,
> to get to green for this story), but you must at least be able to also
> foresee some simple-ish path forward for the other bits you're aware
> that will happen or will be needed (as imperfect and incomplete as that
> understanding might be at that moment.) At the very least, whatever
> you do now in the name of simplicity must not obviously cause complexity
> and trouble come the next story.
>
> So, considering your Singleton example: for this reason, I would
> probably have rejected the whole idea of using a singleton there as I
> would've seen that it probably would not work (or, at least, not in a
> simple manner) when we got to some of the other stories that were in the
> pipeline.
>
> It seems to me that interpreting TSTTCPW in this way thus helps avoid (I
> hope/I think) the oversimplistic thinking that you refer to. Thoughts?
>
> Regards,
>
> Walter
>
> Andrew McDonagh wrote:
> >
> > I'd agreed whole heartedly therefore that Simplest can often be mistaken
> > (whether deliberately or not) as easiest/quickest/most expedient.
> >
> >
>
>
> To Post a message, send it to: extremeprogramming@...
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@...
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

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

Ron Jeffries

... No. It should run the tests, contain no duplication, express all the design ideas presently in it, and minize stuff ... ... A really good moped. ... Except

Message 4 of 22
, Jun 8, 2006

0 Attachment

On Thursday, June 8, 2006, at 3:31:05 PM, Anthony Kaufman wrote:

> Does the simplest design state that you should take into account stories to
> come when constructing your design for the story right now?

No. It should run the tests, contain no duplication, express all the
design ideas presently in it, and minize stuff ...

> If down the road you'll need a plane, but this story only wants something
> that'll drive down the runway, should you construct landing gear and some
> fuselage or just a build a moped?

A really good moped.

> "Right" kindof depends on how things turn out. If you end up constructing a
> plane as was planned, you'll be pleased. Your extra effort to construct
> landing gear and fuselage was worth it.

Except that it was waste investment doing it when all you were doing
was cruising around on the runway ... better to save the time and
money until later.

> However, if all you ever need is
> something that'll drive down a runway, or if your planned "flying" stories
> are scraped and replaced with "drive down the road" stories, you'll have
> wasted time. And until you implement the flying stories you have this weird
> plane shaped vehicle teetering around. Wasn't one of the goals of XP to
> always have an ideal system at the end of an iteration?

Ideal for what it then does. Not ideal for what it will someday do.
The rules of simple design make it ideal for what it has to do next.

> Ideal for what it then does. Not ideal for what it will someday do.
> The rules of simple design make it ideal for what it has to do next.
>

Please help me out a bit.

When I read these types of posts I wonder if the scenario in question
is always contrived with this idea that "we MAY need X, Y, or Z". It
almost sounds like all projects are small and no one incrementally
builds large systems, and no one knows the real customer needs.

Suppose the requirement says, "We need a vehicle that can go down a
runway". Firstly, the term runway is typically in the domain of
aeronautics and so one could ask, "Do you mean you need an airplane,
or do you need a firetruck, or do you need a baggage tractor?" But
maybe I am more familiar with the fashion industry and so I give you
a supermodel on roller blades.

These scenarios are often presented in such a way so that there are
no communication paths available to the developer.

For example, suppose the "product" to be built is an airplane. The
scenario is as if the Project Manager divied up the tasks to
different development teams that can not talk to each other and that
the big picture is only given on a need to know basis. It is like the
PM told one group, "Build me something that can roll down a runway"
and he told another group to "build me something that can seat 8
passengers" and yet a third group he told "build me something that
can make things fly".

There should be a big picture. You should know what is required. If
something comes up that you think may be needed then tell someone so
that it can be determined if something was overlooked. If it is not
an oversight then don't make it. Clearly simple design, regression
tests, properly defined domain, etc., can make the system easy to
extend and from my experience software is usually extended.

Many times I have heard, "xp doesn't mean check your brain at the
door". Making a big picture doesn't mean do BDUF. Understanding your
customer's requirements doesn't mean do BDUF. There is a planning
game to determing the product. Then this product (which is the big
picture) is divided up and releases and iterations are defined and
the product is delivered incrementally.

If you need a tractor, a plane, or a supermodel on roller blades, it
should be known by someone somewhere somehow.

I don't know, but it seems like I am missing something, or
misunderstanding something...

Geoff

Andrew McDonagh

... You are right, there is a big picture, there has been a release planning session and iteration sessions too. That unfortunately is not the issue. Its

Message 6 of 22
, Jun 8, 2006

0 Attachment

geoffrey_slinker wrote:

>
> --- In extremeprogramm
>
> If you need a tractor, a plane, or a supermodel on roller blades, it
> should be known by someone somewhere somehow.
>
> I don't know, but it seems like I am missing something, or
> misunderstanding something...
>
> Geoff

You are right, there is a big picture, there has been a release planning
session and iteration sessions too.

That unfortunately is not the issue. Its blind adherence to Do The
Simplest Thing for the CURRENT iteration.

When ever we create software, there are numerous ways we could do it -
some are more open to change than others. But this flexibility is often
not as Simple as the ridged design. And its the choosing to do the more
ridged design because its Simple that causes the problems.

> geoffrey_slinker wrote:
> >
> > --- In extremeprogramm
> >
> > If you need a tractor, a plane, or a supermodel on roller blades, it
> > should be known by someone somewhere somehow.
> >
> > I don't know, but it seems like I am missing something, or
> > misunderstanding something...
> >
> > Geoff
>
>
> You are right, there is a big picture, there has been a release planning
> session and iteration sessions too.
>
> That unfortunately is not the issue. Its blind adherence to Do The
> Simplest Thing for the CURRENT iteration.
>
> When ever we create software, there are numerous ways we could do it -
> some are more open to change than others. But this flexibility is often
> not as Simple as the ridged design. And its the choosing to do the more
> ridged design because its Simple that causes the problems.

Simplicity satisfies the _real_ requirements of the domain without
a lot of additional cruft, and without throwing all those embarrasing
complexities over the fence for someone else to deal with.

If you tell me that this code, once written, is never, ever going to
be maintained, I'm going to look at you with extreme skepticism.
In fact, if you can't give me a good reason why I should think that,
I'll look at you as either very naive or as lying to me in order to
manipulate me into not doing those things that I know make code
maintainable.

It doesn't matter to me how simple it looks, if it can't be maintained
it's not simple.

John Roth

What makes a design rigid?

>
>
>

Ron Jeffries

... I m not sure how to do a rigid design. I am sure that if the cod runs all the tests, has no duplication, expresses all the design ideas so far, and

Message 8 of 22
, Jun 8, 2006

0 Attachment

On Thursday, June 8, 2006, at 7:32:18 PM, Andrew McDonagh wrote:

> You are right, there is a big picture, there has been a release planning
> session and iteration sessions too.

> That unfortunately is not the issue. Its blind adherence to Do The
> Simplest Thing for the CURRENT iteration.

> When ever we create software, there are numerous ways we could do it -
> some are more open to change than others. But this flexibility is often
> not as Simple as the ridged design. And its the choosing to do the more
> ridged design because its Simple that causes the problems.

I'm not sure how to do a rigid design. I am sure that if the cod
runs all the tests, has no duplication, expresses all the design
ideas so far, and minimizes entities, it's bloody hard to also make
it difficult to change.

Yes, that is a challenge: I'd like to see some code that meets the
Beck rules and is hard to change.

Ron Jeffries
www.XProgramming.com
We know less about the project today than at any time in the future.
-- Chet Hendrickson
You mean today is the dumbest day of the rest of my life?
-- Ron Jeffries

Ron Jeffries

... I shall do my best. (Ben Stein) ... I m not assuming that we don t know, and I m not assuming that things may change. I assert that at any given moment, if

Message 9 of 22
, Jun 8, 2006

0 Attachment

On Thursday, June 8, 2006, at 6:41:51 PM, geoffrey_slinker wrote:

>> Ideal for what it then does. Not ideal for what it will someday do.
>> The rules of simple design make it ideal for what it has to do next.
>>

> Please help me out a bit.

I shall do my best. (Ben Stein)

> When I read these types of posts I wonder if the scenario in question
> is always contrived with this idea that "we MAY need X, Y, or Z". It
> almost sounds like all projects are small and no one incrementally
> builds large systems, and no one knows the real customer needs.

I'm not assuming that we don't know, and I'm not assuming that
things may change. I assert that at any given moment, if we're
implementing feature by feature, the best way for the design to be
is exactly right for the features then implemented, not exactly
right for some future state.

We might wish to explore what would have to be true for that
assertion to be true, depending on where your thoughts, and those of
others, go next.

> Suppose the requirement says, "We need a vehicle that can go down a
> runway". Firstly, the term runway is typically in the domain of
> aeronautics and so one could ask, "Do you mean you need an airplane,
> or do you need a firetruck, or do you need a baggage tractor?" But
> maybe I am more familiar with the fashion industry and so I give you
> a supermodel on roller blades.

It has to pass the customer's tests. The example is amusing but
perhaps too intentionally obtuse.

> These scenarios are often presented in such a way so that there are
> no communication paths available to the developer.

Agile software development /requires/ a communication path to the
developer. Everything I've been talking about so far assumes that
context. On the other hand, without such a path, even if you're
doing waterfall, you don't know whether they want a plane or a
supermodel on wheels.

> For example, suppose the "product" to be built is an airplane. The
> scenario is as if the Project Manager divied up the tasks to
> different development teams that can not talk to each other and that
> the big picture is only given on a need to know basis. It is like the
> PM told one group, "Build me something that can roll down a runway"
> and he told another group to "build me something that can seat 8
> passengers" and yet a third group he told "build me something that
> can make things fly".

Suppose the product is software. We're talking about software and
how to do software. Airplanes are not software. The example won't
fly.

> There should be a big picture. You should know what is required. If
> something comes up that you think may be needed then tell someone so
> that it can be determined if something was overlooked. If it is not
> an oversight then don't make it. Clearly simple design, regression
> tests, properly defined domain, etc., can make the system easy to
> extend and from my experience software is usually extended.

Yes, software is usually extended. Yes, it's good to know where
you're probably going to go.

That emphatically does not imply that you should do extra work now
to prepare for something that is going to happen later.

> Many times I have heard, "xp doesn't mean check your brain at the
> door". Making a big picture doesn't mean do BDUF. Understanding your
> customer's requirements doesn't mean do BDUF. There is a planning
> game to determing the product. Then this product (which is the big
> picture) is divided up and releases and iterations are defined and
> the product is delivered incrementally.

> If you need a tractor, a plane, or a supermodel on roller blades, it
> should be known by someone somewhere somehow.

Sure. It's wonderful to know ...

> I don't know, but it seems like I am missing something, or
> misunderstanding something...

Well, software isn't a tractor, a plane, or even a supermodel on
skates. That could be part of the issue.

The question I was originally answering had to do with whether, at a
given iteration, the design should have in it things preparing for
future iterations. My answer is that, other than being a good design
for the features now in the system, there is no need to put stuff in
for the future. Good design /is/ design for the future: modularity
works.

I don't know at all how to build an airplane by incremental
development with refactoring. I do know a fair amount about how to
build software that way, and I think I can be more helpful talking
about that.

Ron Jeffries
www.XProgramming.com
We cannot solve our problems with the same thinking we used when we created them.
-- Albert Einstein

geoffrey_slinker

(Sorry, but I made a very thought out reply and it seems to have disappeard...) Thanks for your time and your response. ... Yes! Good design /is/ design for

Message 10 of 22
, Jun 9, 2006

0 Attachment

(Sorry, but I made a very thought out reply and it seems to have
disappeard...)

Thanks for your time and your response.

>
> The question I was originally answering had to do with whether, at a
> given iteration, the design should have in it things preparing for
> future iterations. My answer is that, other than being a good design
> for the features now in the system, there is no need to put stuff in
> for the future. Good design /is/ design for the future: modularity
> works.

Yes! Good design /is/ design for the future: modularity works.

XP is the environment in which the developer can apply his skills.
Good design is a skill that can be acquired through lots of study,
experimentation, and application. XP is an excellent environment in
which a developer is trusted and therefor allowed to practice his
profession with excellence.

Thanks,
Geoff

Your message has been successfully submitted and would be delivered to recipients shortly.