Re: What is wrong with OO ?

[peb@transcontech.co.uk ("Paul E. Bennett")]

In article <32aefdb0.406273038@news.nstn.ca>
           tbushell@fox.nstn.ns.ca "Tom Bushell" writes:

> On 11 Dec 1996 03:55:36 GMT, tknarr@xmission.com     ( Todd Knarr )
> wrote:
> 
> >I think the problem with formal design goes right to your point #1,
> >since in most other enginerring disciplines there *isn't* the strong
> >dichotomy between design and implementation. 
> 
> Guess I wasn't clear about what I meant by "dichotomy".  I was
> referring to the fact that in current practice, the design and the
> implementation are almost always distinct artifacts.  The "design" is
> a text, drawings, equations, or whatever.  The "implementation" is
> runnable code.  Designs are models - static, abstract, incomplete -
> not usable except as a precursor to implementation.  Implementations
> are dynamic, tangible, detailed - usable in the real world.
> 
> If you accept this description, then there *is* a dichotomy in most
> other enginering disciplines as well - the design for a car is the
> blueprints, mockup, etc.  The implementation is the drivable car.

Perfect! I am glad that someone else seems to share my views on this.
 
> This dichotomy may make sense for other engineering disciplines, who
> must convert the design (which is information, or "bits", to use
> Negroponte's term) into "atoms".  But for software, it's all bits,
> from design to implementtion!  I'm merely speculating that the
> dichotomy may only exist in software because the disciplines we're
> thinking about emulating do it that way.  

I have no problem in supporting the dichotomy. To me a Software design 
is the source listing, which we will all pore over in review meetings 
and structured walkthroughs, and this is the detailed instructions which 
will enable someone to perform the implementation phase (like handing the 
schematics, PCB layouts, components lists and assembly instructions to the 
equipment manufacturer).
 
> Perhaps this is a fundamental mistake, and we need to think of design
> as an outline, or a scaffold, or a foundation, or whatever other good
> analogies we can come up with, as opposed to a "model".  Perhaps then
> we will not face so much difficulty and resistance to formal design,
> because it will become obvious that this is a worthwhile activity.

Design exists at several levels in all engineering worlds. Concept Design, 
Prototype Design, Product Design, Industrial Design, Detail Design. Which 
level you need to be dealing with depends on how far thorugh your design 
lifecycle you are and what you are designing.
 
> >All too often, though, the "systems analysts" hand me a design document
> >which I'm supposed to implement which is exactly the programming
> >equivalent of that 1000-foot single-span stone bridge.
> 
> This is a very valid point, but in my mind a different issue (although
> related).  In other parts of this thread, we've been talking about the
> "gap" between design and code - the sense that there's a big leap of
> abstraction between current design models and implementable systems.
> 
> I'm not really happy with the way I've explained this, and not even
> sure I believe my own explanations, but will let it stand  until
> something better occurs to me.

If someone wants a 1000-foot single-span stone bridge you can build a 
structure in exotic materials and stone clad it. As long as the customer 
has not visited the site during construction he will never know. I believe 
that we might call this "information hiding" in software.

This thread has been a particularly long one for me to read today (as I have 
just returned to my system after a period away working) and all participants 
have contributed a mixture of interesting ideas and notions, some of which I 
can relate to easily.

We are all going to need a whole range of tools and paradigms to enable us 
to grasp the essentials of what our customers want from the systems we build 
for them. One thing we should all learn from the disasters that have occurred 
in IS design is that failure of projects is a failure of the management of 
the project. The projects that are successful, despite their use of "bleeding 
edge" technology and very difficult concepts are those in which project 
management has been very effective in maintaining discipline and rigour of 
application in the teams.

Choosing an appropriate "lifecycle" model and tools that enable the easy 
support of such a lifecycle would seem to be more worthy than arguing over 
which language a project should be done in. I would hope that we all agree 
that the language should suit the application area and use concepts natural 
to that domain (Application Specific Languages).

The Critical Failure Factors for any project are:

Hostile Culture (in the development or client organisation)
Poor reporting structures [a most important issue to get right]
Over commitment
Political Pressures
Under-estimated Complexity of problem domain (during initial phases)
Poor Consultation
Inappropriate Application (ie: Technical fix for management problem)
High Staff Turnover
Poor Staff Competency
Poor Communication
Inadequate Testing and Validation
Inadequate User Training
Insufficient Review Stages

[the above list is taken "Software Failure: Management failure" by Stephen 
Flowers published by John Wiley and Sons ISBN 0-471-95113-7 and describes many 
IS systems which failed for one reason or another.]

The question therefore is how do we avoid thos CFF's?

You will notice that one item that does not appear in the list is Changing 
Requirements. This is a fact of life for engineers of all disciplines.   
Engineers have to be good at dealing with changes to the requirements and 
manage them in an orderly manner. Rather than spend money on CASE tools why 
not buy a decent Change Management Software Package.

-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely