🚀 go-pugleaf

In article <4l3auv$jnt@onramp.arc.nasa.gov>, lamaster@viking.arc.nasa.gov 
says...
>
>In article <goochb.334.0015B418@rwi.com>, 
>goochb@rwi.com (William D. Gooch) writes:
>
>OTOH, it is interesting that it is in GUI/window development that 
>O-O methods have been *generally* regarded (even by skeptics) as most 
>successful.  So, perhaps, there is some significance after all to such 
>correspondence.  At least, if what you care about is actual productivity,
>rather than an O-O religious experience.  Now, in some applications,
>the GUI is 99% of the app, but in others, I can assure you that it is
>less than 1%.  It may simply be the case that O-O methods are more 
>effective, pragmatically speaking, for the former case than for the
>latter.  Why insist on applying the same techniques to every problem?
>[cliche' of the day: "If the only tool you have is a hammer, 
>everything looks like a nail."]

Software engineering lacks the conventionalized techniques and terminology 
developed with centuries of practise in other fields such as architecture or 
mechanical engineering, and often even the conventional terminology and 
conceptual foundations that allow an architect to discuss with relative ease 
the problems of live loading on a building structure with an engineer.

GUIs however seem to become one of those areas that are (now) highly 
conventionalized and easy to analyze because the problem in fact was 
decomposed into a metaphorical framework at Xerox Parc over a decade ago.  No 
reasonably computer literate person needs the concept of a window explained 
to them.

Often I've witnessed software development teams accepting the tandem problem 
of decomposing an unconventional and original problem and learning new 
techniques and technologies for doing so.  The novelty of both have negative 
symbiotic effects on each other.  The relativity immaturity of software 
engineering further complicates the task.  It is often difficult to 
communicate the foundational concepts to team members of varying levels of 
training and understanding, and managers and team leaders haven't the 
experience to tailor roles, training and responsibilities appropriately.  
This is a recipe for disaster, and the price of failed software projects, 
cost overruns and late delivery is estimated in the Saganesque billions and 
billions per year in North America.

GUIs by now are as much a cooked and 'toy' problem as those found in 
introductory OO books -- there exist straightforward and automatic 
decompositions of the problem into classes and class hierarchies, and in fact 
many GUI frameworks representing pre-fab applications.  They possess another 
attractive attribute -- they are highly visual and therefore susceptible to 
the architectonic (~spatio-temporaral) analysis that many engineers, 
mathematicians and computer scientists excel at (who tend to be the people 
doing software development).

This does not mean that OOT fails at unconventional problems, but that many 
fail to recognize that with such problems an extra step is involved in 
decomposing the problem into appropriate elements at an appropriate level of 
abstraction.  This happens in architecture, mathematics, science, engineering 
and so on -- these fields usually just have frameworks handed down from 
decades or centuries of practise, a legacy either software engineering 
doesn't enjoy or isn't recognized by undertrained practioners.  Software 
engineering is also an applied science, which requires appreciation of the 
domain to which it is applied.  Most of us have so long used and played with 
and programmed GUIs that we can consider ourselves de facto 'domain experts'. 
Confronted with other domains, developers often fail to recongize the need 
for this domain expertise.

What I find *consistently* are software teams that employ OOADP to describe a 
linear, structured solution to their problem.  Having typically 1-12 years 
experience solving problems in software their minds have been trained to 
operate this way.  Like breaking away from any habit, those adopting OO are 
going to find their technique suffers until OO becomes natural -- the new 
habit replacing the old.  You can teach people all the OOADP you want, and 
without integrating the new thinking into their work they can readily bend 
all that teaching to developing and describing old-style solutions.  OOT can 
only support, and not enforce, the new paradigms.  And BTW, OOADP introduces 
awful and needless overhead and complexity into linear, structured software 
solutions, so that people who abuse OO (as I said in an earlier post) come to 
blame OO for introducing awful and needless overhead and complexity.  It is 
fairly difficult to describe a blueprint for a building using calculus 
notation or Lisp syntax, but that isn't a failing of calculus or Lisp.

The great divide in OO separates those who understand the notations, the 
languages, and the jargon and those who've grokked the fundamental paradigm 
shift (a la Kuhn).  This might actually get back to the subject that started 
this thread an era ago: a mind trained to one paradigm (the, let us say 
somewhat archetypal, C hacker) more strongly resists the new paradigm than 
the tabula rasa.  I think that is Bertrand Meyer's hypothesis, and not an 
established fact, and even if true the C hacker archetype also carries many 
other skills and qualities that might outweigh this disadvantage.

Most people need to recover the architectonic thinking so natural to them and 
discard training forced upon them by a more primitive level of technology.  
Use Cases can be taught in a three day course, OMT a four day course, C++ or 
Eiffel a four day course, but getting people to again trust themselves and 
their natural patterns of thought after years of shoehorning their thinking 
into unnatural patterns to accomodate the technology is bloody difficult 
(IME).

OOT's power is that it supports natural ways for humans to reason about 
problems, and by notation to communicate that reasoning to other humans in 
reasonably natural form.  But all the computer still understands is opcodes, 
and all technologies only add notational or expressive power *for the benefit 
of humans*.  And I might claim that OO has higher general notational and 
expressive power across a wider spectrum of domains than other technologies.


-- 
Brad Shapcott, Technical Consultant
Lockheed-Martin's Advanced Concepts Center
Ottawa, Canada (613) 592-8744 x227