Re: [AM] Let's call a spade a spade

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Are you looking for savings on products you use everyday?=20
Visit Quality Health today and see the coupons, free=20
samples and special offers our members enjoy each and=20
everyday.
http://click.topica.com/=
caab3ozbUrKDAbWnbtka/ Ivo Interactive
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Peter Lynch wrote:
>=20
>  I agree about OO implementation, it has ended up as the aim rather than =
the
> tool.

I think it depends on how well one understands OO.  Those who
understand it well can, and usually do, use it as a tool.  Those
who do not understand it well are sufficiently challenged by=20
the intricacies of OO that OO itself becomes a goal, diverting
focus from the software problem it is intended to help solve.


>  But has not OO suffered the same as Agile is suffering - the intent is l=
ost
> in a cacophony of words. Words from people who know no more than the word=
s

This gets to the next obvious question -- _how_many_ developers are=20
sufficiently challenged by OO to be adversely affected by it?  These=20
are likely the same ones who get "lost in a cacophony of words."
(Nicely articulated, BTW)  A web page that gives one insight into=20
this "how many" question is  http://www.acm.org/sigsoft/SEN/parnas.html

This page is a 1999 interview with David Parnas, the "father of
information-hiding."  (Info-hiding one of the two most important
underlying concepts of OO, the other being the idea of modeling
real-world objects.)  In this interview, Parnas says

  "I don't think that the most promising ideas are on the horizon.=20
  They are already here and have been here for years but are not
  being used properly....The biggest payoff will not come from new=20
  research but from putting old ideas into practice and teaching=20
  people how to apply them properly."

It is pretty clear that info-hiding is one of the ideas he is
referring to.  He appears to think that a LOT of people are
not using it properly, which implies a widespread lack of=20
understanding of basic OO concepts.

Thus, one of the founding fathers of OO appears to agree with=20
your assessment.


> themselves - with no internal model which allows differentiation between
> software choices, usually managers who left their technical areas too ear=
ly
> in the pursuit of success and prestige.


I think the idea of an "internal model" to differentiate software=20
choices is a VERY important observation.  In fact, it is so
important that I have actually developed such a model. It is an
explicit model (that is, capable of being written down), is=20
customer-centric, and also software quality-centric.  It would be
off topic for this thread to explain it here. Maybe in another=20
posting if there is sufficient interest in the group.

Anyway, excellent observation -- but easier said than done!


>  After OO was implemented in C and other mainstreams from models like Eif=
fel
> and Smalltalk, the masses believed that OO was fully defined and implemen=
ted
> by that model. But before those implementations manifested, the CONCEPT o=
f
> OO was being discussed and pursued by small groups, usually in software
> bureaux, where conventional development was not an option. The now accept=
ed
> definition of OO is one of the many ways the concept could have (and has)=

> manifested.


Your implication is that OO as we know it is not the only way to=20
implement these concepts.  Again, one need not look any farther
than Parnas to prove you are right.  When Parnas and his team
invented the term "information-hiding", they envisioned it being
applied to three major types of information to facilitate ease of
change of this information:

1. Software interfaces to hardware
2. Design decisions
3. Required behavior

Current OO focuses only on item 2 in the form of data and data structures.

Item 1 is being practiced by operating system developers in the form
of device drivers, but is divorced from mainstream OO.  In fact the
OS developers do not consider themselves to be using OO.  How
many OS's are written using "OO"?  I only know of one -- Steve Job's
NeXT.  Maybe there are a few others, but the OS industry as a whole
is still wedded to function design, even though their use of device
drivers to encapsulate hardware interfaces makes them 'just as OO'
as OO (i.e., both encapsulate only one major kind of information
for ease of change.)

Hardly anyone in the industry today even remembers that Parnas said
*requirements* could be encapsulated for ease of change.

So you are clearly right -- over 20 years ago Parnas and his team
drew a roadmap for OO that is far from being met by OO as we know=20
it today.  There is clearly a lot of room for improvement.

<aside>
A NASA Space Station team I was on over 10 years ago developed
a form of OO that addressed all three, but most notably item 3,
requirements.  We felt this 'requirements encapsulation' methodology=20
represented a major advance conceptually over current OO.  (You=20
sure managed to hit my 'hot buttons' with this posting, Peter! :-)
</aside>


>  I always have had trouble with the OO implementations. I found them less=

> effective than the techniques I was currently using, and still use. One d=
ay,


Peter, I'd be interesting in hearing about these better techniques
you are currently using.  If you think they are off topic for the=20
group, please email me personally.  Thanks.



> in the late 80's, I asked a fresh graduate whether he could summarize wha=
t
> he understood of OO. His answer was "What, not how". I really like that
> answer.


Of course, "What, not how" is the traditional answer to the question
"What are requirements?" (a little bit of Jeopardy)=20=20

In the context of OO, "What, not how" refers to interfaces. When we=20
were formulating the requirements encapsulation methodology for NASA,=20
we discovered the two meanings were actually coincident.


>  Is that not also at the essence of Agile? Manage the technical in such a=

> way that there is a beneficial interaction between user and developer? Wh=
at
> am I doing, not how will I implement this.


I could not agree more.  The requirements encapsulation
methodology does exactly this -- recording requirements
in a manner that permits their encapsulation for ease of
change leads naturally to an improvement in "beneficial=20
interaction between user and developer."=20=20

This, among other things, led me to believe the methodology=20
was highly consistent with agile principles,  However, many
agilists who have looked at the web site or read various
papers about the methodology disagree.  I strongly suspect=20
this is due to a misunderstanding of the methodology.  Some=20
methodologies are difficult to fully comprehend solely from=20
literature. As in the case of agile and AM, understanding is=20
best achieved by doing.

--=20
Rick Lutowski
Principal, JReality
[email protected]
http://www.jreality.com

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
**** Bounces like rubber! Shatters like ceramic! ****
Discover Crazy Aaron's Thinking Putty in grown up=20
handfuls. It's the creativity unleashing, mood enhancing=20
desk toy!
http://click.topica.com/=
caab5n2bUrKDAbWnbtkf/ Crazy Aaron Enterprises
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

For more information about AM, visit the Agile Modeling Home Page at www.ag=
ilemodeling.com
--^----------------------------------------------------------------
This email was sent to: =
[email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.=
bWnbtk.=
Z2NtYS1h
Or send an email to: [email protected]

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=3DTEXFOOTER
--^----------------------------------------------------------------