Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.c++,comp.client-server
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!newsfeed.internetmci.com!in2.uu.net!projtech!daemon
From: steve@projtech.com
Subject: Re: SCRUM and Why the Waterfall Methodology is a Fool's Errand ... 
X-Nntp-Posting-Host: sallys
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <NEWTNews.817961724.22597.steve@sallys.projtech.com>
Lines: 105
Sender: daemon@projtech.com
Organization: Project Technology, Inc.
X-Newsreader: NEWTNews & Chameleon -- TCP/IP for MS Windows from NetManage
References: <30AF370B.1AE@vmark.com> <jzqcvc@bmtech.demon.co.uk> <48spd4$s30@ixnews4.ix.netcom.com> <30B34179.66AF@oma.com> <NEWTNews.817067535.430.steve@sallys.projtech.com>  <49d874$qub@ixnews5.ix.netcom.com> 
Mime-Version: 1.0
Date: Sun, 3 Dec 1995 01:06:29 GMT
Xref: glinda.oz.cs.cmu.edu comp.object:41891 comp.lang.smalltalk:31461 comp.lang.c++:163102 comp.client-server:14215


In article <49d874$qub@ixnews5.ix.netcom.com>, <kentb@ix.netcom.com> writes:
> In <NEWTNews.817067535.430.steve@sallys.projtech.com>
> steve@projtech.com writes: 
> >Paul's text above is indeed how we view it: The first step in the 
> >Shlaer-Mellor method is to identify the layers, by identifying 
> >subject matters (we call them problem domains), and depicting
> >the dependencies between the layers in a "domain chart".
> >
> >Then we analyze each domain (each layer) independently of one another.
> >...
> >I quote again the last three lines of the original post:
> >> >    ...........  Most development organizations still prefer a
> >> > pile-of-paper-based illusion of control to active management of
> >> > development risk.
> >
> >I suggest that a process that:
> >
> >1. Identifies the domains (layers) in the system, as the first step
> >2. Immediately moves to understand (and document) the dependencies 
> >   between the domains
> >3. Analyzes each domain separately and (relatively) independently
> >
> >is taking on active management of development risk, through explicit
> >management of the dependencies between the layers. Further, we
> >begin this very early on in the development process.  Finally I say
> >for one last time, that such a process is not a waterfall.

> The worst risks in the world are integration risks, because you can't
> possibly find them until you see the whites of their eyes. If the
> domains are all well understood, such risk is minimized because you
> know where the landmines are buried. This is never the case for
> interesting software. Most competitive software developers are forced
> to innovate in several domains at once.
> 
> I recommend to my clients that they use practices that maximize
> communication between developers of dependent layers-
> shoulder-to-shoulder development, episodic design (Ward Cunningham's
> phrase- see the Episode patterns in http://c2.com/ppr), group CRC
> review, and Grady's vertical slice-o-functionality.
> 
> I agree with Robert Martin- integrate early, integrate often.

In many systems, even interesting ones, many domains _are_ understood.
I therefore continue to recommend that one should deliver the domains
closest to the machine (OS, Network) first, and then those close to 
the outside world (user interface, process i/o. 

There is value--in a limited number of cases--in delivering only 
vertical portions of _some_ of these domains.  For example, I might
put together a project plan that delivers _all_ of the OS and Network,
but only the Digital Input quarter of the PIO, so that the hardware
engineers may do their job.  Or all the OS, simple IPC within a 
single machine and the output-only display subsystem so I can
_show_ something.  Certainly, I would deliver, initially, only
one (or in a push two) vertical slices of the application.

That said, your point is a very good one: Integration problems
are the worst.  But there are two kinds of integration problem.
One is that caused by misunderstanding the dependencies between
domains (or layers, if you prefer).  These problems are relatively
easy to manage: make explicit the assumption-requirement pairs
between layers.  Of course, this does presume the existence
of these management skills.  A problem that is missed--especially
a performance problem--can be a bear to fix.  But it will be 
localized, especially if using full translation capability so
that a change may be easily propagated throughout newly generated
code.

The second type is peer-to-peer communication between implemented
subsystems.  For example, there may a misunderstanding between
the group working Trading vs that working Accounting.  Each of these
problems is MUCH easier to fix (because each is purely local--
between an object in trading and an object in accounting, say), but 
they tend to be more widespread and much less easy to find.
We have tried for years to address these problems by building
firewalls: "Let's just define the interface and let my Atlanta team
loose.  Y'all in London just make sure you adhere to the interface."
Yeah, right.  Excessive vertical-slice-o'-functionality deliveries
exacerbate this problem, not alleviate it.  (My use of the word
"excessive" is intended exactly as stated.  It is not an attempt
to shift the emotional focus of the reader.)

Today's received wisdom makes both iteration and incremental
delivery the "third rail" of software development--touch it
and die!  After all, if your analysis tools are advisory
and your management skills weak, what options do you have?
The problem here is that THE SOLUTION VALIDATES THE PROBLEM.
The more you partition into vertical slices, the more
integration problems you have, so the more vertical slices
you make.

I submit that one should deliver lower (closest to the machine)
layers first.  And the more uncertain of your understanding
of the _system_ that you are, the more you should attempt to 
push upwards towards the application to deliver a vertical 
slice-o'-functionality.  If all you're doing is delivering
vertical slices, then this is an admission that you have no
idea what's going on in the system as a whole.

At the risk of agreeing with RCM, I say integrate early and 
often--just make sure you do so from the bottom layer up.

-- steve mellor




