Simplest Thing That Works for domain model vs for architecture

Simplest Thing That Works for domain model vs for architecture

Post by Paul Campbel » Thu, 20 Feb 2003 03:50:32



Pretty much all of the discussion of the merits of using the STTW approach
has been in the context of domain model evolution - employee types etc etc.
Now Im willing to accept that STTW is a fair aproach to use here because
business organisation type domain models tend to change in unpredicatable
ways and the probability of missdirected futureproofing is high.

But I think some questions need to be asked:

1) Are problem domains in general as fluid and unpredictable as bus org
structures ?. I certainly know some that are not (such as network managment
models). I have to say that the frequent citing of bus org examples to support
STTW reminds me of  how people used to use image processing examples to
demostrate how parralel precessing was supposedly going to revolutionise
computing.

2) Is frequent refactoring at the architectural level expensive to the point
where we simply *must* "give it our best shot" in terms of taking reasonable
futureproofing steps ?. IME the aswer is a clear YES. The reason is this:
architecture level interfaces (between sub-systems) are fundamentally
different in nature to the normal object collaboration interfaces. All
experienced distributed system designers know that it is nearly impossible
to take a previosly monolithic application, split it up using a remoting tech
such as CORBA, and expect it to work effeciently without wholesale
redesign of the interfaces the boundaries. At these interfaces we prefer
to pass around data structures (yes Value Oblects are essentially structs)
and monikers or keys instead of actual object references. We also have
to build in a layer of fault tolerance on either side of this interface
that we did not need before.

Paul C.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by John Rot » Thu, 20 Feb 2003 13:22:09




Quote:> Pretty much all of the discussion of the merits of using the STTW
approach
> has been in the context of domain model evolution - employee types etc
etc.
> Now Im willing to accept that STTW is a fair aproach to use here
because
> business organisation type domain models tend to change in
unpredicatable
> ways and the probability of missdirected futureproofing is high.

Actually, this isn't really true, if you've got the *real* domain model.
That may not be the model you actually use for construction the system,
but it's the one you use for talking to the customer.

Quote:> But I think some questions need to be asked:

> 1) Are problem domains in general as fluid and unpredictable as bus
org
> structures ?. I certainly know some that are not (such as network
managment
> models). I have to say that the frequent citing of bus org examples to
support
> STTW reminds me of  how people used to use image processing examples
to
> demostrate how parralel precessing was supposedly going to
revolutionise
> computing.

The trouble with "The simplest thing that could possibly work" as a
guideline is that the people who preach it have a more elaborate model
of "work" than the people who misuse it.

"Work" in this context includes the notion that the result has to lead
to
a well designed program that will not cause difficulty being extended
later
to include requirements that are known (but not scheduled now) or that
could reasonably be expected even if they aren't officially on the
table.

Notice that I said "will not cause difficulty being extended," not
"includes the additional requirments." Mostly this simply means paying
attention to well known software engineering good practice, as well
as the standard XP refactoring guidelines.

Quote:> 2) Is frequent refactoring at the architectural level expensive to the
point
> where we simply *must* "give it our best shot" in terms of taking
reasonable
> futureproofing steps ?. IME the aswer is a clear YES. The reason is
this:
> architecture level interfaces (between sub-systems) are fundamentally
> different in nature to the normal object collaboration interfaces. All
> experienced distributed system designers know that it is nearly
impossible
> to take a previosly monolithic application, split it up using a
remoting tech
> such as CORBA, and expect it to work effeciently without wholesale
> redesign of the interfaces the boundaries. At these interfaces we
prefer
> to pass around data structures (yes Value Oblects are essentially
structs)
> and monikers or keys instead of actual object references. We also have
> to build in a layer of fault tolerance on either side of this
interface
> that we did not need before.

Is this really true? It seems that there are only two things that impede
our ability to evolve systems to accomodate new requirements in a
clean manner. They are: coupling and non-agile tool sets in some
sections
of the system.

Building on my comments about TSTTCW above, I'd expect a properly
constructed application to have minimal coupling in places where it
would
be logical to split it. That wouln't be a result of planning, it's a
result of
a concious attempt to minimize coupling and maintain good practice. If
a "monolithic" system hasn't been constructed this way, I can see why
splitting it would be a rather difficult matter.

John Roth

- Show quoted text -

Quote:

> Paul C.


 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Paul Campbel » Thu, 20 Feb 2003 18:34:28



> The trouble with "The simplest thing that could possibly work" as a
> guideline is that the people who preach it have a more elaborate model
> of "work" than the people who misuse it.

> "Work" in this context includes the notion that the result has to lead
> to
> a well designed program that will not cause difficulty being extended
> later

Stop right there - sorry but either you are doing "blind" refactoring taking
*no account whatsoever of future design direction* OR you are future proofing
to some extent, I am not going to let you have it both ways. Additionally
any notion of taking account of future direction seems to be fundamentally
at odds with test first design.

Quote:> to include requirements that are known (but not scheduled now) or that
> could reasonably be expected even if they aren't officially on the
> table.

This doesnt tally with what other XP people are saying - they are saying
they deliberately ignore future design direction. The way I read it is that
zero investement in future design/architecture is *fundamental* to XP
(more specifically fundamental to test first design).

Also allow me to quote my own answer to a simmilar thread elsewhere:

---
The problem I am having with the XP possition is the meaning of the word "Works"
is STTW: either it means "Provides well factored but minimally sufficient
fucntionality being delivered now" OR it means "Takes into account future design
and architecture direction in the minimal way that is consistent with being easily
extended in such directions". Now I have seem plenty of quotes from XP people
who say very explicitly that they do not do the latter - they deleberatly put
future direction out of thier minds. Thus I think I can reasonable conclude that
with the latter defintion of Works, that STTW isnt really STTW at all.
--

Quote:

> Notice that I said "will not cause difficulty being extended," not
> "includes the additional requirments."

And how on earth can you be sure it wont be difficult to extend without
taking into account future design direction  - how do you know you
are not heading into a Local Maxima ? (note I am taking from an
architectural perspective).

Quote:>  Mostly this simply means paying
> attention to well known software engineering good practice, as well
> as the standard XP refactoring guidelines.

> > and monikers or keys instead of actual object references. We also have
> > to build in a layer of fault tolerance on either side of this
> interface
> > that we did not need before.

> Is this really true? It seems that there are only two things that impede
> our ability to evolve systems to accomodate new requirements in a
> clean manner. They are: coupling and non-agile tool sets in some
> sections
> of the system.

Simply not true - distributed systems are often very highly coupled
across layers.  Is it common for differnt layers in a system to be to work in
lock-step and make sometimes complex assumptions about the behaviour of the
other layers in order to avoid fine grained access accross the layers.

Quote:> Building on my comments about TSTTCW above, I'd expect a properly
> constructed application to have minimal coupling in places where it
> would
> be logical to split it.

The Point is that you are not "logically" splitting it, but splitting it physically.
Splitting at the minimal logical coupling point may not work - two classes may
only communicate by one type of message and yet still be *ed by network
invocation latency if that one method was called synchronously 1000 times a
second.

Quote:> result of
> a concious attempt to minimize coupling and maintain good practice. If
> a "monolithic" system hasn't been constructed this way, I can see why
> splitting it would be a rather difficult matter.

Even if it has it can (IME will almost certainly be) hard to the point of not
being economical.

Paul C.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Ron Jeffrie » Thu, 20 Feb 2003 19:40:38


On Wed, 19 Feb 2003 09:34:28 -0000, "Paul Campbell"


>The problem I am having with the XP possition is the meaning of the word "Works"
>is STTW: either it means "Provides well factored but minimally sufficient
>fucntionality being delivered now" OR it means "Takes into account future design
>and architecture direction in the minimal way that is consistent with being easily
>extended in such directions". Now I have seem plenty of quotes from XP people
>who say very explicitly that they do not do the latter - they deleberatly put
>future direction out of thier minds.

For the record, I have not said the above. I don't put anything out of my MIND.
I put a lot of things out of my code.

I do in fact focus more on well factored minimally sufficient code delivered
now. I do that because, having tried it, I have found that that practice leaves
the door open for the future changes that inevitably come along, whether
predictable or not. I do it because, having done so consciously and
contemplatively, I have encountered none of the things I would have feared about
such an approach.

What might I fear about such an approach? Basically two things: either it would
go just so far and then some change would be terribly difficult to make, or
things would just take longer due to more and more rework as predictable new
things came along.

Those fears have not been borne out in fact, in spite of pushing the "ignore the
future" technique to the limits in my own work and thought over the past few
years.

However, it's important to emphasize that I do not do these things
thoughtlessly.  The fact that I do contemplate what might happen in the future
means that I may be unconsciously selecting directions today which have a higher
chance of working in the future than other directions which might have seemed
reasonable to someone doing less thought, or with less experience.

Suppose that were true. It would be OK with me. It would neither surprise me nor
dampen my enthusiasm for simple design were someone to point out that it works
best if the programmer is thoughtful and applies all his experience.

Quote:> Thus I think I can reasonable conclude that
>with the latter defintion of Works, that STTW isnt really STTW at all.

I don't understand this comment. Are you saying that code which "Takes into
account future design and architecture direction in the minimal way that is
consistent with being easily extended in such directions" is somehow not the
simplest code that could possibly work?

The idea behind either Kent's or my formulation of the "simplest thing that
could possibly work" notion is thoughtful selection of a solution that meets two
criteria: it is simple, and it could work. It is always a matter of thoughtful
judgment.

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Ron Jeffrie » Thu, 20 Feb 2003 19:55:08


On Wed, 19 Feb 2003 09:34:28 -0000, "Paul Campbell"



>> The trouble with "The simplest thing that could possibly work" as a
>> guideline is that the people who preach it have a more elaborate model
>> of "work" than the people who misuse it.

>> "Work" in this context includes the notion that the result has to lead
>> to
>> a well designed program that will not cause difficulty being extended
>> later

>Stop right there - sorry but either you are doing "blind" refactoring taking
>*no account whatsoever of future design direction* OR you are future proofing
>to some extent, I am not going to let you have it both ways. Additionally
>any notion of taking account of future direction seems to be fundamentally
>at odds with test first design.

I'm not sure why you would want to set this as the rule.  We're always thinking
about the future while we program for today.

The point of simple design, refactoring, and TDD isn't that stupid blind tiny
testing leads to good things. The point is that by /thoughtfully/ choosing
simple solutions, /thoughtfully/ refactoring to modular communicative code,
/thoughtfully/ selecting tests that lead to small learnings and continuous
improvement in the code's functionality ... /thoughtfully/ doing these things
leads to designs of the same or higher quality than the heavier up front work we
used to do before.

No one gets a lobotomy to do these practices. They add to what we already know.
They don't take away.

Regards,

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Ron Jeffrie » Thu, 20 Feb 2003 19:56:47


On Wed, 19 Feb 2003 09:34:28 -0000, "Paul Campbell"


>The problem I am having with the XP possition is the meaning of the word "Works"
>is STTW: either it means "Provides well factored but minimally sufficient
>fucntionality being delivered now" OR it means "Takes into account future design
>and architecture direction in the minimal way that is consistent with being easily
>extended in such directions". Now I have seem plenty of quotes from XP people
>who say very explicitly that they do not do the latter - they deleberatly put
>future direction out of thier minds.

For the record, I have not said the above. I don't put anything out of my MIND.
I put a lot of things out of my code.

I do in fact focus more on well factored minimally sufficient code delivered
now. I do that because, having tried it, I have found that that practice leaves
the door open for the future changes that inevitably come along, whether
predictable or not. I do it because, having done so consciously and
contemplatively, I have encountered none of the things I would have feared about
such an approach.

What might I fear about such an approach? Basically two things: either it would
go just so far and then some change would be terribly difficult to make, or
things would just take longer due to more and more rework as predictable new
things came along.

Those fears have not been borne out in fact, in spite of pushing the "ignore the
future" technique to the limits in my own work and thought over the past few
years.

However, it's important to emphasize that I do not do these things
thoughtlessly.  The fact that I do contemplate what might happen in the future
means that I may be unconsciously selecting directions today which have a higher
chance of working in the future than other directions which might have seemed
reasonable to someone doing less thought, or with less experience.

Suppose that were true. It would be OK with me. It would neither surprise me nor
dampen my enthusiasm for simple design were someone to point out that it works
best if the programmer is thoughtful and applies all his experience.

Quote:> Thus I think I can reasonable conclude that
>with the latter defintion of Works, that STTW isnt really STTW at all.

I don't understand this comment. Are you saying that code which "Takes into
account future design and architecture direction in the minimal way that is
consistent with being easily extended in such directions" is somehow not the
simplest code that could possibly work?

The idea behind either Kent's or my formulation of the "simplest thing that
could possibly work" notion is thoughtful selection of a solution that meets two
criteria: it is simple, and it could work. It is always a matter of thoughtful
judgment.

Regards,

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Paul Campbel » Thu, 20 Feb 2003 21:08:42



> On Wed, 19 Feb 2003 09:34:28 -0000, "Paul Campbell"

> >The problem I am having with the XP possition is the meaning of the word "Works"
> >is STTW: either it means "Provides well factored but minimally sufficient
> >fucntionality being delivered now" OR it means "Takes into account future design
> >and architecture direction in the minimal way that is consistent with being easily
> >extended in such directions". Now I have seem plenty of quotes from XP people
> >who say very explicitly that they do not do the latter - they deleberatly put
> >future direction out of thier minds.

> For the record, I have not said the above. I don't put anything out of my MIND.
> I put a lot of things out of my code.

> I do in fact focus more on well factored minimally sufficient code delivered
> now.
> What might I fear about such an approach? Basically two things: either it would
> go just so far and then some change would be terribly difficult to make, or
> things would just take longer due to more and more rework as predictable new
> things came along.

> Those fears have not been borne out in fact, in spite of pushing the "ignore the
> future" technique to the limits in my own work and thought over the past few
> years.

Well I have just been bitten directly by it - somone on my team used test
first design and deliberately ignored a definate  future (at the time) requirement
of persistence. The rework required to add persistence was much higher than
if it had been taken account of initially. The guy who did this now admits that
he was wrong to not bear definite future requirements in mind.

Quote:

> However, it's important to emphasize that I do not do these things
> thoughtlessly.  The fact that I do contemplate what might happen in the future
> means that I may be unconsciously selecting directions today which have a higher
> chance of working in the future than other directions which might have seemed
> reasonable to someone doing less thought, or with less experience.

If you are going to preach some principal called STTW then please please
be at pains to qualify it as you have here with your consideration
of the big picture. Because in its raw literal form it is down right dangerious
IME.

Quote:

> > Thus I think I can reasonable conclude that
> >with the latter defintion of Works, that STTW isnt really STTW at all.

> I don't understand this comment. Are you saying that code which "Takes into
> account future design and architecture direction in the minimal way that is
> consistent with being easily extended in such directions" is somehow not the
> simplest code that could possibly work?

If it takes any account of future direction then it is not the simplest thing that
works *today* because it probably contains extra hooks or indirection levels
that would make future extension easier, and if so then it  it is not the simplest thing
that would make the tests work *today*.

Quote:>The idea behind either Kent's or my formulation of the "simplest thing that
>could possibly work" notion is thoughtful selection of a solution that meets two
>criteria: it is simple, and it could work.

According to my interpetation of english there is no hint whatsoever of any
consideration of future design direction in those two criteria, assuming
that "work" means "passes todays tests". If  "work" infact has some wider
meaning then prehaps that needs stating explicitly.

Paul C.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Ron Jeffrie » Thu, 20 Feb 2003 21:27:23


On Wed, 19 Feb 2003 12:08:42 -0000, "Paul Campbell"


>> What might I fear about such an approach? Basically two things: either it would
>> go just so far and then some change would be terribly difficult to make, or
>> things would just take longer due to more and more rework as predictable new
>> things came along.

>> Those fears have not been borne out in fact, in spite of pushing the "ignore the
>> future" technique to the limits in my own work and thought over the past few
>> years.

>Well I have just been bitten directly by it - somone on my team used test
>first design and deliberately ignored a definate  future (at the time) requirement
>of persistence. The rework required to add persistence was much higher than
>if it had been taken account of initially. The guy who did this now admits that
>he was wrong to not bear definite future requirements in mind.

It would be interesting to understand what happened and why. I haven't
encountered cases where well-factored code was that difficult to change.

Quote:

>> However, it's important to emphasize that I do not do these things
>> thoughtlessly.  The fact that I do contemplate what might happen in the future
>> means that I may be unconsciously selecting directions today which have a higher
>> chance of working in the future than other directions which might have seemed
>> reasonable to someone doing less thought, or with less experience.

>If you are going to preach some principal called STTW then please please
>be at pains to qualify it as you have here with your consideration
>of the big picture. Because in its raw literal form it is down right dangerious
>IME.

It's a sentence, Paul. It's a reminder of a complex practice. Nothing we do can
be captured effectively in one sentence.

Quote:

>> > Thus I think I can reasonable conclude that
>> >with the latter defintion of Works, that STTW isnt really STTW at all.

>> I don't understand this comment. Are you saying that code which "Takes into
>> account future design and architecture direction in the minimal way that is
>> consistent with being easily extended in such directions" is somehow not the
>> simplest code that could possibly work?

>If it takes any account of future direction then it is not the simplest thing that
>works *today* because it probably contains extra hooks or indirection levels
>that would make future extension easier, and if so then it  it is not the simplest thing
>that would make the tests work *today*.

I do not agree. I find that code need not have hooks to be prepared for the
future. I think that putting in hooks today, and putting them in tomorrow
generally has the same cost, and that deferring that cost until needed is a
reasonable thing to do.

Why would an edit be substantially harder tomorrow than today? In general, I
find that it is not. If going along we saw a place where the change would be
more costly later than today, and we were sufficiently sure we would need it,
then I suppose we might do it.

What I've been doing for the past five years is working with as little of that
as possible, and I'm here to report that IF you follow the rules of simple
design, it seems that far less installation of "hooks" is necessary than I used
to think.

Quote:

>>The idea behind either Kent's or my formulation of the "simplest thing that
>>could possibly work" notion is thoughtful selection of a solution that meets two
>>criteria: it is simple, and it could work.

>According to my interpetation of english there is no hint whatsoever of any
>consideration of future design direction in those two criteria, assuming
>that "work" means "passes todays tests". If  "work" infact has some wider
>meaning then prehaps that needs stating explicitly.

The consideration of future design direction is modularity. Modularity works.
Simple design plus tests support refactoring. Refactoring to the Beck rules of
simple design produces modularity -- high cohesion and low coupling. Modularity
produces code that is easy to change in the future.

I find that doing more than that is rarely necessary. But it is simply false to
imagine that making the code modular does not take the future into account. On
the contrary, making the code modular is probably the most important thing we
can do for the future of the code.

Do you see my point? I'm not saying don't work for the future. I'm saying simple
design plus refactoring supported by tests IS work for the future and that
additional "hooks" are rarely necessary.

Regards,

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by S Perryma » Thu, 20 Feb 2003 21:41:45



Quote:> Pretty much all of the discussion of the merits of using the STTW approach
> has been in the context of domain model evolution - employee types etc
etc.
> Now Im willing to accept that STTW is a fair aproach to use here because
> business organisation type domain models tend to change in unpredicatable
> ways and the probability of missdirected futureproofing is high.
> But I think some questions need to be asked:
> 1) Are problem domains in general as fluid and unpredictable as bus org
> structures ?. I certainly know some that are not (such as network
managment
> models).

Network management models are certainly not rigid and predictable.
Unless :

1. You live on slow-changing model definitions (such as those from the ITU)
.
2. You work on 'single scheme' comms/telecoms technologies (an SDH-only
   system etc) .

Quote:> 2) Is frequent refactoring at the architectural level expensive to the
point
> where we simply *must* "give it our best shot" in terms of taking
reasonable
> futureproofing steps ?. IME the aswer is a clear YES. The reason is this:
> architecture level interfaces (between sub-systems) are fundamentally
> different in nature to the normal object collaboration interfaces. All
> experienced distributed system designers know that it is nearly impossible
> to take a previosly monolithic application, split it up using a remoting
tech
> such as CORBA, and expect it to work effeciently without wholesale
> redesign of the interfaces the boundaries. At these interfaces we prefer
> to pass around data structures (yes Value Oblects are essentially structs)
> and monikers or keys instead of actual object references. We also have
> to build in a layer of fault tolerance on either side of this interface
> that we did not need before.

The problem is more fundamental on that.
On large-scale systems where division of labour is based on clean functional
boundaries, frequent churn becomes intolerable.

That is one reason why I and others do some up-front analysis at the
system/domain levels.

This can be done before, or in conjunction with lower-level development
activities (the latter is a very good way of steering the system at the "big
picture" level while giving the lower-level activities the autonomy to do
their thing - the big picture issues are usually the ones that make/break a
system IMHO) .

Regards,
Steven Perryman

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by John Rot » Thu, 20 Feb 2003 21:42:18







> > On Wed, 19 Feb 2003 09:34:28 -0000, "Paul Campbell"

> > >The problem I am having with the XP possition is the meaning of the
word "Works"
> > >is STTW: either it means "Provides well factored but minimally
sufficient
> > >fucntionality being delivered now" OR it means "Takes into account
future design
> > >and architecture direction in the minimal way that is consistent
with being easily
> > >extended in such directions". Now I have seem plenty of quotes from
XP people
> > >who say very explicitly that they do not do the latter - they
deleberatly put
> > >future direction out of thier minds.

> > For the record, I have not said the above. I don't put anything out
of my MIND.
> > I put a lot of things out of my code.

> > I do in fact focus more on well factored minimally sufficient code
delivered
> > now.

> > What might I fear about such an approach? Basically two things:
either it would
> > go just so far and then some change would be terribly difficult to
make, or
> > things would just take longer due to more and more rework as
predictable new
> > things came along.

> > Those fears have not been borne out in fact, in spite of pushing the
"ignore the
> > future" technique to the limits in my own work and thought over the
past few
> > years.

> Well I have just been bitten directly by it - somone on my team used
test
> first design and deliberately ignored a definate  future (at the time)
requirement
> of persistence. The rework required to add persistence was much higher
than
> if it had been taken account of initially. The guy who did this now
admits that
> he was wrong to not bear definite future requirements in mind.

What did he do, and what should he have done? As specifically as
possible
without showing code.

My guess is that he scattered access logic all over the place rather
than
centralizing it. In other words, he either violated encapsulation or
"once and only once."

- Show quoted text -

Quote:

> > However, it's important to emphasize that I do not do these things
> > thoughtlessly.  The fact that I do contemplate what might happen in
the future
> > means that I may be unconsciously selecting directions today which
have a higher
> > chance of working in the future than other directions which might
have seemed
> > reasonable to someone doing less thought, or with less experience.

> If you are going to preach some principal called STTW then please
please
> be at pains to qualify it as you have here with your consideration
> of the big picture. Because in its raw literal form it is down right
dangerious
> IME.

> > > Thus I think I can reasonable conclude that
> > >with the latter defintion of Works, that STTW isnt really STTW at
all.

> > I don't understand this comment. Are you saying that code which
"Takes into
> > account future design and architecture direction in the minimal way
that is
> > consistent with being easily extended in such directions" is somehow
not the
> > simplest code that could possibly work?

> If it takes any account of future direction then it is not the
simplest thing that
> works *today* because it probably contains extra hooks or indirection
levels
> that would make future extension easier, and if so then it  it is not
the simplest thing
> that would make the tests work *today*.

This can be debated endlessly to no result. The key concept here is
that the entire reason for XP is to create a program we *know* can
be extended in the future. Anything that does not further this basic
concept is outside of the bounds of *can work*.

XP depends on adhering to fundamental software engineering practice
to get there, it does not depend on adding specific features today for
anticipated future requirements.

Quote:> >The idea behind either Kent's or my formulation of the "simplest
thing that
> >could possibly work" notion is thoughtful selection of a solution
that meets two
> >criteria: it is simple, and it could work.

> According to my interpetation of english there is no hint whatsoever
of any
> consideration of future design direction in those two criteria,
assuming
> that "work" means "passes todays tests". If  "work" infact has some
wider
> meaning then prehaps that needs stating explicitly.

That's why I brought it up. I've seen entirely too many reports of
people
taking TSTTCPW as a license to quit thinking about all those hard things
they should have learned in software engineering class.

It isn't. It's an injunction against gold-plating, and it only works if
you
always keep in mind future agility.

John Roth

- Show quoted text -

Quote:

> Paul C.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Paul Campbel » Thu, 20 Feb 2003 22:39:55



> On Wed, 19 Feb 2003 12:08:42 -0000, "Paul Campbell"

> It would be interesting to understand what happened and why. I haven't
> encountered cases where well-factored code was that difficult to change.

Because we use a java serialisation based persistence mechanism, and thus there
must be no outward referential links from the classes being persisted, thus listener
style callbacks to monitor model changes that would otherwise be quite reasonable
end up dragging in the whole world. Granted this problem is specific to the
mechanism but it was know at the time that we were going to do it this way.

Quote:> >If you are going to preach some principal called STTW then please please
> >be at pains to qualify it as you have here with your consideration
> >of the big picture. Because in its raw literal form it is down right dangerious
> >IME.

> It's a sentence, Paul. It's a reminder of a complex practice. Nothing we do can
> be captured effectively in one sentence.

But I am saying its worse than that - its a dangerous over simplification, and I have
both direct and indirect experience of people taking it literally - when I see comments
from people doing test first design who say stuff like "... then I code until I get a green
line (in junit)" then its a good bet that there isnt much holistic design consideration going
on here.

I guess unltimately Im not criticising what you are actualy doing so much as how
other people are interpreting the guidlines and I guess that isnt your fault :-).

Why not use "the simplest design that takes account of the likely future design
and architecture evolution" if thats what you really mean.

Quote:> >If it takes any account of future direction then it is not the simplest thing that
> >works *today* because it probably contains extra hooks or indirection levels
> >that would make future extension easier, and if so then it  it is not the simplest thing
> >that would make the tests work *today*.

> I do not agree. I find that code need not have hooks to be prepared for the
> future. I think that putting in hooks today, and putting them in tomorrow
> generally has the same cost, and that deferring that cost until needed is a
> reasonable thing to do.

> Why would an edit be substantially harder tomorrow than today? In general, I
> find that it is not. If going along we saw a place where the change would be
> more costly later than today, and we were sufficiently sure we would need it,
> then I suppose we might do it.

Remeber this thread is about architectural evolution. I accept that co resident
class design for business logic rarely need speculative hooks.

Architectural design however does because interfaces must be designed differently
at subsystem boundaries for instance: using an actual object reference as a paramater
 is cheap (very) between co resident classes whereas it is often the most expensive sort
of data item to pass over a link in a ditributed object system. Its much cheaper
to design the relevent parts of the system to use keys or monikers from the outset than it
is to retro fit. And there are of course many other factors such as call latency and fault
tolerance that must be considered and I dont want to be retro fitting these into a design
that took no account of it either.

Paul C.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Paul Campbel » Thu, 20 Feb 2003 22:54:54





> > Pretty much all of the discussion of the merits of using the STTW approach
> > has been in the context of domain model evolution - employee types etc
> etc.
> > Now Im willing to accept that STTW is a fair aproach to use here because
> > business organisation type domain models tend to change in unpredicatable
> > ways and the probability of missdirected futureproofing is high.

> > But I think some questions need to be asked:

> > 1) Are problem domains in general as fluid and unpredictable as bus org
> > structures ?. I certainly know some that are not (such as network
> managment
> > models).

> Network management models are certainly not rigid and predictable.

No they arent but I was making a relative statement vs a typical business
organistion based app where changes can result from the whim of a
director rather than from months or years of work by methodical engineers
who are mindful of the ramifications.

Quote:> > such as CORBA, and expect it to work effeciently without wholesale
> > redesign of the interfaces the boundaries. At these interfaces we prefer
> > to pass around data structures (yes Value Oblects are essentially structs)
> > and monikers or keys instead of actual object references. We also have
> > to build in a layer of fault tolerance on either side of this interface
> > that we did not need before.

> The problem is more fundamental on that.
> On large-scale systems where division of labour is based on clean functional
> boundaries, frequent churn becomes intolerable.

Indeed, I clean forgot about such developement  logistic concerns, probably
because are doing everying (elements + manager) in one location here. This
is of course not typical, and one would normally expect interfaces to be finalised
quite early on for that reason alone.

Quote:> That is one reason why I and others do some up-front analysis at the
> system/domain levels.

> This can be done before, or in conjunction with lower-level development
> activities (the latter is a very good way of steering the system at the "big
> picture" level while giving the lower-level activities the autonomy to do
> their thing - the big picture issues are usually the ones that make/break a
> system IMHO) .

That is bassically whats going on here: architecturally we are trying to think
ahead (measured in years) while the local sub-sys dev is more "agile" in
nature.

Paul C.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Ron Jeffrie » Thu, 20 Feb 2003 22:53:20


On Wed, 19 Feb 2003 13:39:55 -0000, "Paul Campbell"



>> On Wed, 19 Feb 2003 12:08:42 -0000, "Paul Campbell"

>> It would be interesting to understand what happened and why. I haven't
>> encountered cases where well-factored code was that difficult to change.

>Because we use a java serialisation based persistence mechanism, and thus there
>must be no outward referential links from the classes being persisted, thus listener
>style callbacks to monitor model changes that would otherwise be quite reasonable
>end up dragging in the whole world. Granted this problem is specific to the
>mechanism but it was know at the time that we were going to do it this way.

I'm wondering why no tests or stories caused this problem to go on for so long
without being discovered, given that it was known as an issue.

Quote:

>> >If you are going to preach some principal called STTW then please please
>> >be at pains to qualify it as you have here with your consideration
>> >of the big picture. Because in its raw literal form it is down right dangerious
>> >IME.

>> It's a sentence, Paul. It's a reminder of a complex practice. Nothing we do can
>> be captured effectively in one sentence.

>But I am saying its worse than that - its a dangerous over simplification, and I have
>both direct and indirect experience of people taking it literally - when I see comments
>from people doing test first design who say stuff like "... then I code until I get a green
>line (in junit)" then its a good bet that there isnt much holistic design consideration going
>on here.

>I guess unltimately Im not criticising what you are actualy doing so much as how
>other people are interpreting the guidlines and I guess that isnt your fault :-).

I rather like to think that. If people read what we write, I think they'll get
it. If they take 8 words out of context, they might not.

Quote:

>Why not use "the simplest design that takes account of the likely future design
>and architecture evolution" if thats what you really mean.

That isn't what we mean. This must be more difficult to explain than I ever
knew.

Do the simplest thing that could possibly work. If you know it couldn't work, do
not do it. To be simple, code must, in priority order,

1. Run all the tests;
2. Contain no duplication;
3. Express all the ideas the programmers want to express;
4. Minimize the number of classes and methods.

Did the serialization issue you mentioned above meet these criteria? If so, or
if not, how did that impact the difficulty of doing the changes?

- Show quoted text -

Quote:

>> >If it takes any account of future direction then it is not the simplest thing that
>> >works *today* because it probably contains extra hooks or indirection levels
>> >that would make future extension easier, and if so then it  it is not the simplest thing
>> >that would make the tests work *today*.

>> I do not agree. I find that code need not have hooks to be prepared for the
>> future. I think that putting in hooks today, and putting them in tomorrow
>> generally has the same cost, and that deferring that cost until needed is a
>> reasonable thing to do.

>> Why would an edit be substantially harder tomorrow than today? In general, I
>> find that it is not. If going along we saw a place where the change would be
>> more costly later than today, and we were sufficiently sure we would need it,
>> then I suppose we might do it.

>Remeber this thread is about architectural evolution. I accept that co resident
>class design for business logic rarely need speculative hooks.

OK ...

Quote:

>Architectural design however does because interfaces must be designed differently
>at subsystem boundaries for instance: using an actual object reference as a paramater
> is cheap (very) between co resident classes whereas it is often the most expensive sort
>of data item to pass over a link in a ditributed object system. Its much cheaper
>to design the relevent parts of the system to use keys or monikers from the outset than it
>is to retro fit. And there are of course many other factors such as call latency and fault
>tolerance that must be considered and I dont want to be retro fitting these into a design
>that took no account of it either.

Yes. When such systems are released, they need hooks. To find out what kind of
hooks they need, I'd suggest writing some applications on both sides of the gap,
to find out what they actually need. What would you do?

--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

 
 
 

Simplest Thing That Works for domain model vs for architecture

Post by Richard MacDonal » Fri, 21 Feb 2003 00:09:27




> On Wed, 19 Feb 2003 13:39:55 -0000, "Paul Campbell"



>>> On Wed, 19 Feb 2003 12:08:42 -0000, "Paul Campbell"

>>> It would be interesting to understand what happened and why. I
>>> haven't encountered cases where well-factored code was that
>>> difficult to change.

>>Because we use a java serialisation based persistence mechanism, and
>>thus there must be no outward referential links from the classes being
>>persisted, thus listener style callbacks to monitor model changes that
>>would otherwise be quite reasonable end up dragging in the whole
>>world. Granted this problem is specific to the mechanism but it was
>>know at the time that we were going to do it this way.

Ah yes. Great example. Quite likely the simplest approach *now*.
Definitely a serious limitation *later*.

Quote:> I'm wondering why no tests or stories caused this problem to go on for
> so long without being discovered, given that it was known as an issue.

I think this architectural limitation is easy to know beforehand. But
until you have a specific performance requirement, java serialization
might be good enough. Suddenly you hit the wall. The "fix" is a soft
statement and not really testable. How would you write: "Don't serialize
the whole world because it won't scale" as a test?

Quote:>>> >If you are going to preach some principal called STTW then please
>>> >please be at pains to qualify it as you have here with your
>>> >consideration of the big picture. Because in its raw literal form
>>> >it is down right dangerious IME.

>>> It's a sentence, Paul. It's a reminder of a complex practice.
>>> Nothing we do can be captured effectively in one sentence.

>>But I am saying its worse than that - its a dangerous over
>>simplification, and I have both direct and indirect experience of
>>people taking it literally - when I see comments from people doing
>>test first design who say stuff like "... then I code until I get a
>>green line (in junit)" then its a good bet that there isnt much
>>holistic design consideration going on here.

Its a bad bet when the person doing this is a very good developer. That
person may have a very good idea of the "layout of the long road ahead",
but also appreciates the value of taking small steps and unambiguous
indications that one is still on the tarmac.

Quote:>>I guess unltimately Im not criticising what you are actualy doing so
>>much as how other people are interpreting the guidlines and I guess
>>that isnt your fault :-).

> I rather like to think that. If people read what we write, I think
> they'll get it. If they take 8 words out of context, they might not.

>>Why not use "the simplest design that takes account of the likely
>>future design and architecture evolution" if thats what you really
>>mean.

> That isn't what we mean. This must be more difficult to explain than I
> ever knew.

Yes it is. Because the benefits are subtle and profound, i.e., hard to
believe, and the fear (reality) of the local optimum is rather too well
experienced in our industry.

Quote:> Do the simplest thing that could possibly work. If you know it
> couldn't work, do not do it. To be simple, code must, in priority
> order,

> 1. Run all the tests;
> 2. Contain no duplication;
> 3. Express all the ideas the programmers want to express;
> 4. Minimize the number of classes and methods.

> Did the serialization issue you mentioned above meet these criteria?

Quite easy to imagine it did. Until one day a new test concerning
performance ran into a serious rewrite in order to pass.

Quote:> If so, or if not, how did that impact the difficulty of doing the
> changes?

Paul, how well was the serialization encapsulated? If you'd TDD'd it,
then it would be very well encapsulated. Perhaps you could have then
written a new serialization component that only serialized a portion of
the world and replaced the "ends" with references. (If your objects
serialized themselves, how hard would it have been to have this delegated
instead as a prior refactoring step?)
 
 
 

1. Simplest Thing That Works for domain model vs for architecture

Pretty much all of the discussion of the merits of using the STTW approach
has been in the context of domain model evolution - employee types etc etc.
Now Im willing to accept that STTW is a fair aproach to use here because
business organisation type domain models tend to change in unpredicatable
ways and the probability of missdirected futureproofing is high.

But I think some questions need to be asked:

1) Are problem domains in general as fluid and unpredictable as bus org
structures ?. I certainly know some that are not (such as network managment
models). I have to say that the frequent citing of bus org examples to support
STTW reminds me of  how people used to use image processing examples to
demostrate how parralel precessing was supposedly going to revolutionise
computing.

2) Is frequent refactoring at the architectural level expensive to the point
where we simply *must* "give it our best shot" in terms of taking reasonable
futureproofing steps ?. IME the aswer is a clear YES. The reason is this:
architecture level interfaces (between sub-systems) are fundamentally
different in nature to the normal object collaboration interfaces. All
experienced distributed system designers know that it is nearly impossible
to take a previosly monolithic application, split it up using a remoting tech
such as CORBA, and expect it to work effeciently without wholesale
redesign of the interfaces the boundaries. At these interfaces we prefer
to pass around data structures (yes Value Oblects are essentially structs)
and monikers or keys instead of actual object references. We also have
to build in a layer of fault tolerance on either side of this interface
that we did not need before.

Paul C.

2. FS:Hardware!

3. xp: more thought vs. simplest thing that works

4. Navigation bars and subwebs

5. more thought vs. simplest thing that works

6. Visual C++ and DirectX question

7. Domain model vs. Analysis model vs. Design model - Help!

8. Windows NT 4.0 BDC to Windows 2000 Domain

9. How to check NT-machines group model (Domain-Model or Workgroup-Model) ?

10. Object models, Domain models, Application models, and MVC?

11. Help with CryptoAPI: can not do the simplest thing!!!

12. The Simplest Thing? (was: OO fanatics: switch lo...)

13. Hyper-cube Structure Experiment (was: Simplest Thing...)