Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!netcomsv!jls
From: jls@netcom.COM (Jim Showalter)
Newsgroups: comp.object
Subject: Re: Negative Reaction to OOT
Message-ID: <1991May16.001902.19888@netcom.COM>
Date: 16 May 91 00:19:02 GMT
References: <10954@rama.UUCP> <1991May15.193212.29506@m.cs.uiuc.edu>
Sender: netnews@netcom.COM (USENET Administration)
Distribution: na
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 35
Originator: jls@netcom.netcom.com

>There are some design methods that can be used to reduce the chances
>of having problems, but there is no design method (for anything) that
>guarentees success the first time.  To engineer is human.  It is
>funny that people know this about programs but don't seem to realize
>that it is just as true of architectures.

An architecture needs to be prototyped, just like anything else. The
initial design of the architecture is theory; the initial prototype
is experiment. For large projects with complex architectures, it is
reasonable to make a number of successively better passes at the
architecture, each with a refined prototype. This is NOT a waste of
money or an unecessary delay--it is the only way I'm aware of to
stand any reasonable chance of success. It is quite acceptable to
build a prototype that represents 5-10% of the total final size of
the project in SLOC--for a million line project, this is 50-100K,
all of which may well be thrown away except for the overall subsystem
decomposition and set of exported interfaces.

The cost of prototyping an architecture can be more easily justified
if it spans more than one specific project: indeed, it makes excellent
business sense. Suppose, for example, some company has a division that
specializes in building air defense systems and air traffic control
systems. Using the typical approach, each new such system would be
built using a blank sheet of paper approach. How much more sensible it
is to acknowledge the area(s) of specialization, and commit division-wide
resources to devising an architecture sufficiently general to be used
for all such systems. This "line-of-business" focus when designing an
architecture is rare, but I have seen it used on a series of four
ship designs with a resulting reuse of 70% and a savings to the customer
of $117 million.
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 *****************
* Proven solutions to software problems. Consulting and training in all aspects*
* of software development. Management/process/methodology. Architecture/design/*
* reuse. Quality/productivity. Risk reduction. EFFECTIVE OO techniques. Ada.   *