Conference 7.286::digital

    re .0
    
    An analogy --
    
    Company A & B are in a race to deliver products x and y, respectively, 
    two products that are to provide essentially the same functionality.  
    Company A can deliver product x in 6 months.  Company B can deliver
    product y in 2 years. Product x will consume 3 times as many "fttts" as
    product y when in operation.  Interestingly, "fttts" are getting
    cheaper, in 2 years "fttts" will be 1/4 to 1/8 as cheap as they are
    today.  Customers of companies A & B want products x or y today.  Also
    interestingly, companies A & B make products that also produce "fttts",
    they are able to charge more for the products that produce more "fttts".  
    
    Which company's stock would you buy?

    In DEC, "RAD" = "Research Advanced Development", a committee ot oversee
    such. - Fred

    DECRAD, a Layered Product to organize info for radiation laboratories.
    - Fred

    Back to the subject (or debate) at hand -
    
    
    It's not the original cost of development that differentiates Q&Ds
    (quick and dirty [ old name for RAD]) from CASE - it's the cost
    of ongoing maintainance and enhancements.
    
    Try going back a year later to work w/ a system that has no
    meta-structure and documentation managing the design and implementation
    organization!
    
    

    The gains from CASE are not at question. What is at question is where
    you draw the line. "Time to Market" is the point. Contrary to what
    we would all no doubt prefer, business needs define systems - not
    vice-versa. A perfectly documented, fully-tested system is useless
    if it is two years late - the business has changed (or gone bust).
    
    Mike Day
    

    >"Time to Market" is the point. 

Of course, that begs the question: Time to Market for which version?
Time to Market for the first release will be shortened by RAD, at the expense
of rigorous design and testing.  What happens to our market when we come
out with a product which has bugs and missing features, promising to "clean
it up in the next release", and then the next release gets pushed way out
because of the lack of a CASE methodology?  How do you enhance a product
which was not well engineered in the first place?

I think that in the long run we lose all the way around by doing things
Q&D.    

Kevin

>What happens to our market when we come
>out with a product which has bugs and missing features, promising to "clean
>it up in the next release", and then the next release gets pushed way out
>because of the lack of a CASE methodology?  How do you enhance a product
>which was not well engineered in the first place?

There's another factor involved here, too:  the COST OF SUPPORT quick and
dirty products.  Hey, if we come out with a product in 6 months, and sell lots
of them, our revenue goes up.  Once the customers start calling, our expenses
go up -- probably even more!

Also... when we ship a quick and dirty first release, what does that do to the
market for the next release?

Bob Leigh
CSSE

    Let's distinguish here between system software and business
    applications.  System software tends to be "forever" (VMS and UNIX are
    both around 20 years old).  A lot of business applications are obsolete
    after a year or two - the business conditions they were created to
    address have ceased to exist.  Business systems also tend to have a
    value expressible in dollars per unit time.  If the application will
    save $50,000/month, it is effectively COSTING me $50,000 for each extra
    month I spend in development.  

    Most business applications I've worked on have been designed for no more
    than a 5-year life span.  Once in place, changes tended to be largely
    cosmetic - add a field, change a calculation, reformat a report.  We
    didn't ignore maintainability issues.  They simply weren't our primary
    concern.  Getting the blasted thing up and running before the users
    decided they wanted something completely different was the key.

    Another issue addressed by RAD is the basic fact that most business
    users have a really hard time telling you what it is they want in the
    abstract.  A methodology based on rapid prototyping lets you reach the
    desired goal by showing the user alternatives.  Once they've seen
    something, they can generally say if it's "right" or "wrong".

    There may be more than one measure of goodness.
    
    -dave

    Another factor to consider is the 'fit' of the application to the
    environment it will run in.   Rigorously designed systems sometimes
    have easily changed/maintained exteriors but rock solid interior
    logical assumptions about the business that the application will
    run in.   
    
    If the interior is at odds with the business environment it won't
    ever work, no matter how well it is written, unless the user changes
    the business model to map to the logical model assumed by the designer.
    This is not easily accomplished.
    
    I've seen crudely written software (homegrown) work quite nicely
    because it grew very naturally from the environment where the business
    problem that was targeted also grew.

    I can remember, not too many years ago, when "prototyping" was a bad
    word - at least in my neck of the Digital woods.  An advocate could get
    labeled "troublemaker" quite easily.  There is still a lot of it around
    I'm afraid.
    
    How many times have you been told "Do it right the first time"?  Sorry,
    but for me, I do not do many things right the first time.  Human nature
    being what it is usually means that no one else wants to admit they are
    in the same boat.  But, please, do not take this too seriously.  If I
    were boss, I'd say the same I guess: Plan it right, do it right, do the
    right thing - first time.  It is possible, but not usually at the right
    price or time schedule for both vendor and customer.  Proof?  Warranty
    period.
    
    Folks who think they can, or have had some luck or something, get to be
    the bosses.  They are welcome to it.  Some apparently acutally enjoy
    straightening out messes.
    
    Fred

	... in the future EIS organization, IMHO.  There is another phrase to
the "Do it right, now..." motto, and that is

			"...or do it OVER later!"

Prototyping will help in a couple of places: - up-front customer approval of the
user interfaces (Functional Spec quality), and validation of some high-level
data flows and processing (System Design quality).  For the code/test phase, as
a previous reply noted, code-generators are going to dominate, along with usable
test managers.

	After almost 14 years in the field SWS, I have seen most custom projects
fail because of too little, or low quality, up-front work to focus the end-user
on what they needed to really solve their problem, AND PUTTING IT ON PAPER, OR
IN FRONT OF THEIR EYES AND HANDS.  The results typically being a system that
passed the ATP, but didn't SATISFY anyone, or else one that could NEVER pass an
ATP because of mis-setting expectations.

	For those of you interested in pursuing this train of thought in the
realm of the new EIS organization, may I offer the conference:

			SOADC::PSS

as an appropriate forum to discuss both selling AND delivery issues.

    There is an assumption (by some) that RAD is quick and dirty.  Maybe
    some RAD has been done that way but it does not have to be the rule.  I
    equate RAD (properly done) to be "quick (non elegant) and perhaps slow."  
    Those of us pointing out the advantages of a RAD kind of product are
    not advocating a dirty product.

    To this debate I would offer a modest hypothesis, based on these
    observations:
    
      (1)  The customers do not know what they want.  Often they do
           not know what they need either.  Ocasionally they do not
           understand their business anymore.
    
      (2)  When customers do understand their business, and know what
           they want or need, they do not generally know how to communicate
           this to developers.
    

    These two problems are the critical ones facing most software projects.
    They can both be solved by multiple methods.
    
    The choice of CASE or RAD strategies is meaningful only when it
    gives the developer an advantage in solving the definition or
    communications problems.
    
    I would like to understand what that advantage might be.  Any thoughts?
    
    

    According to the EIA (Electronics Industry Association) programmer
    productivity is increasing at about 4% a year (better methods and
    procedures) and the number of programmers are increasing at about
    8% a year. Unfortunately, the numbers of lines per typical program
    and numbers of programs being requested are are growing at about
    50% a year.
    
    Using CASE to automate requirements analysis, design, configuration
    management, and system building will only make a small increase
    in productivity compared to what is required. RAD is the only means
    of keeping pace.
    
    As systems become more complex, the specifications must become more
    high level. That is, more abstract and less detailed specifications
    generate complete code. This trend is starting to happen and will
    continue. Eventually, we'll all be programmers without even knowing
    it. We'll make requests to a computer and it'll write a program within
    milliseconds to service that request.
    
    -George

    re .13
    
    such arrogance!  You don't appear to give our/your customers credit for
    very much.  
    From a customer's viewpoint the situation is more like this:
    
      (1)  Digital does not understand or know what we want or need.  Often 
    	   they do not understand our business anymore.
    
      (2)  When Digital does understand our business, and know what we
           want and need, they do not generally know how to communicate
           this to developers.
    
      (3)  When Digital developers think they understand our business and
    	   think they know what we need, they do not know how to verify
    	   and communicate this with us.
    
      (4)  Worst of all is when Digital thinks they understand our business 
    	   and really don't, and never bother to check and ignore any data
    	   to the contrary.
    
    Fortunately, this isn't true in a majority of the cases. Unfortunately,
    the fact that it is true at all, is a problem.
    
    Back to the subject, the usefulness of RAD is that it could be used to
    help verify and establish customer needs, helping solve some of the
    customer problems above (instead of waiting for two years to find out
    you didn't get the right requirements communicated).

    I am sorry the hypothesis presented in .13 appears "arrogant". 
    It is admittedly an extreme case.  The description in .15 is better
    phrased, and brings out additional features of what I believe the
    fundamental problems are, that confront the software industry.
    
    The process of communicating requirements between a customer and
    a developer is subject to distortion and breakdown at every step.
    The process of defining requirements within a customer organization
    can be derailed by rapidly changing business conditions, or by 
    severe conflicts within the organization, such that clearly
    communicated requirements are still infeasable.  Both of these 
    conditions are extremely common.
    
    So how might a CASE strategy solve a communications problem between
    customer and developer?  How might a RAD strategy solve the same
    kind of problem?
    
    What will the CASE strategy prescribe when functional requirements
    seem infeasble or inconsistent with the customer's business?  What
    can be done using RAD?
    
    

    I didn't see .13 as being at all arrogant.  I flet it pretty fairly
    summed up the situation - not just Digital vs. cusotomer, but also
    in-hose developers vs. their own users.
    
    The people whose jobs required them to USE computer systems are neither
    systems analysts or programmers.  They aren't very good at specifying
    functionality in the abstract.  In many cases, the analyst is required
    to interface with clerical personnel who understand their jobs in terms
    of specific operations, but have little awareness of the broader
    business context.
    
    All of these conditions make it essential that the development process
    have room for feedback at all stages.  To the extent that CASE
    methodologies place primary emphasis on "internal" considerations like
    provable correctness, maintainability, etc. they miss the mark.
    
    As far as the dictum about "doing it right the first time" goes, I ould
    respond with Gerald Weinberg's first law of system development.
    
    "PLAN to throw version 1.0 away.  You will, anyway!"
    
    
    -dave

    re .17
    
    The arrogance and conceit I detect in your statements and those
    initially made by .13 are: 1) it is the customer's problem that YOU
    can not understand what they need, and 2) if the customer had YOUR
    perspective, they would obviously agree with or understand YOUR view of
    what the solution should be.  As long as developers have that attitude,
    Digital will always be short of its potential.
    
    Your statement demonstrates this:
    >The people whose jobs required them to USE computer systems are neither
    >systems analysts or programmers.  They aren't very good at specifying
    >functionality in the abstract.  In many cases, the analyst is required
    >to interface with clerical personnel who understand their jobs in terms
    >of specific operations, but have little awareness of the broader
    >business context.
    
    Let me reword that from the customer's view.
    I'm not a system analyst nor programmer.  System analysts and
    programmers want me to explain my requirements in their terms.  They
    seem to have difficulty understanding abstract concepts like:  make it
    easier to use, make it simple, make it obvious, make my job more
    rewarding.  They have little awareness of the context in which I do my 
    job.  Etc.
    
    As a system analyst, your job should be to understand what it is like
    to walk a mile in their shoes, not for them to fit it to your shoes.
    
    One of the more successful projects we've done for a customer involved
    periodic review by the "clerks" who were the ultimate users of the
    system.  The "clerks" sat down and attempted to use the system.  When
    they got up after a 1/2 hour totally pissed and frustrated, changes
    were made to accomodate them.
    
    What RAD can do is help the system analyst who doesn't understand his
    customer's needs to get a better understanding of them.  I certainly
    wish it had been done with some of the products I have to offer to
    customers.
    
    The rest of your statements were right on.

    re .18;
    
    I think we're in violent agreement.  I didn't say that the customers
    are stupid.  Nor do I insist that they do it my way.  I do think that
    we need to have a realistic understanding of where ourt non-technical
    users are coming from.  Their inability to think about systems in
    terms of abstract models and descriptions is OUR problem, not theirs.
    
    Your example is exactly the sort of thing I'm getting at.  Users may
    not know what they want, but if you show them something, they sure as
    heck know what they DON'T want.  The problem with traditional analysis
    methodologies is that they bury non-technical users under mountains of
    abstract descriptions (functional specs).  I've seen users sign off on
    specs they had neither read nor understood simply because they a)
    didn't want to look "stupid" and b) had been given a deadline for
    signoff.  Once we went and built something based on those specs, they
    immediately "understood" and were able to explain what was wrong with
    the thing and why.
    
    The worst arrogance is looking at methodologies and "quality" in terms
    of our technical concerns rather than in terms of there ability to help
    us realize usable systems.
    
    -dave

    The author of .15 and .18 appears to believe that "arrogant" developers
    fail to understand customer requirements, but that rapid application
    delivery can provide feedback that may correct this problem.  The
    author does not seem to believe that a customer can define "bad"
    requirements, but rejects this hypothesis as "conceited".  I see
    lots of raw nerve endings exposed here!
    
    The author of .17 and .19 appears to accept both the communications
    problem and the definition problem as valid ideas.  He (she?) points
    out that feedback from rapid delivery can correct both problems.
    CASE strategies are described as solving the wrong problems, a point
    also made in note 14.
    
    Is that it then (Fast feedback forstalls failures)?  Shall we load
    up our skeleton programs and grow prototypes at the drop of an RFP?
    How much core information must be gathered to start a sucessfull
    proto?  What are the limits to the technique?  How can pathological
    growth patterns be spotted and prevented?
    

    re .19
    
    Dave,
    
    I'm glad we agree.  However, I'm going to pick at something you said
    because I think it's a key element in viewing "customers."  And it 
    really is a difficency in the way specs are done.
    
    >Their inability to think about systems in
    >terms of abstract models and descriptions is OUR problem, not theirs.
    
    You see, it's not their inability to think about the systems in abstract
    models, because that's exactly what they do.  Specification systems
    require us to put those abstract models into specific "ins" and "outs."
    It's our inability to spec that abstract model in terms of a specific
    computer/program model.
    
    For example, how do you model the following:  easy to use, job rewarding,
    non-confrontive, intuitive, comprehensive, etc?  Yet, those are most
    likely the critical success factors in programs humans interact with. 
    When doing specs though, we typically cover the comprehensive part and
    not the others.  If you think back about highly successful programs,
    you will probably find that somehow they were more than comprehensive.
    
    The point I'm trying to make is that when your viewpoint switches from
    "the customer can't correctly spec it", to "my models can't correctly 
    spec it or understand it."  There is a subtle and significant change 
    in the way the job is approached.  viewpoint -> attitude -> solution
    With the "the customer can't spec it" viewpoint, the attitude is "I'll
    develop it the way I see fit and check with the customer later (since
    we can't spec it adequately anyway)."  With the "my models ..."
    viewpoint, the attitude is "I'd better review carefully or come up with
    dummy test models or involve the customer more or ?"
    
    I'm not happy with my examples but hopefully you see the difference.  I
    think that's what the rest of your statements were trying to get at too.
    This is why RAD and some viewpoint-attitude changes could be very
    valuable to Digitial.
    
    David

    re .20
    
    Your questions raise important issues.  Let's avoid the rathole of my
    inappropriate use of the labels "arrogant" and "conceited."

    re .21;
    
    Now I understand.  Yes.  Customers do express highly abstract "quality"
    concerns that our models don't handle.  They also have trouble
    understanding what the realization will look like by reading lengthy
    specification documents.  
    
    Both these conditions tend to indicate that the development of a
    functional description must be a highly interactive, shared endeavor
    that will involve concrete realizations of some, if not most, of the
    application's external interfaces.
    
    I believe DIS is currently using a  methodology that provides for
    prototyping in a formal development model that addressessome of the
    concerns in .20.  Any DIS folks out there who'd care to comment?
    
    -dave

I think one of our first RAD tools was Datatrieve with FMS.  It allowed the user
to see what his screens and reports would look like in a very short time, with
real data.

Unfortunately, once you got the user to that point, he would take this "thing"
you developed for him and proceed to turn it loose on a 1-gigabyte database.
Of course, it ran horrible, but we never had time to write the application in a
more efficient language because the user now had other things he wanted us to
do.  A few more of these "things" and you could turn a 9000 into a uVAX 2000.

Bob

re: .23

>    I believe DIS is currently using a  methodology that provides for
>    prototyping in a formal development model that addressessome of the
>    concerns in .20.  Any DIS folks out there who'd care to comment?

I hope they didn't use this tool when they designed ELF V2, or we are in
a lot worse shape than we think.


Bob

    re:  Customer knowledge
    
    Actually, in dealing with any organization that has been around for 
    more than a few years, or any business system that has been around for
    more than a few years, there is a good chance that, in fact, NOBODY
    ACTUALLY KNOWS HOW IT WORKS!  Why?  Lots of reasons:
    
    1)  The people who created it are gone or have been doing something 
        else for a while.
    
    2)  Large or small tweaks have been made as new people come and go 
        or the organization changes with time and nobody has kept the 
        original documentation up to date.  (Sound familiar?)
    
    3)  Business conditions or requirements have changed since the 
        system was created (but not enough to make it obvious that it 
        no longer meets requirements, maybe because one of the undocumented 
        tweaks is compensating for the change).
    
    4)  Etc....
    
    Some organizations are scrupulous about maintaining procedures and
    documentation AND training people to follow them.  Not many of the
    organizations I've worked with in DEC, though.  Of course, few managers
    like to admit that they don't REALLY know all that much about what is
    going on, they just think they do.  (Hmmm.  Why should I blame
    managers?  Lot's of people share that trait to some degree or other,
    including yours truly.)
    
    Forget CASE and RAD till later.  First you need a good systems
    archeologist and social anthorpologist.
    
    /Dave

    re .26;
    
    It's not just the "what" that disappears in the depths of time, it's
    the "why".   In the course of re-doing several large business systems
    I've found a good bit of my time spent in tracking down who originally
    requested quirky functions and odd-ball reports. Typically the
    originator is long gone while the organization continues to crank out
    the blasted report with absolutely no idea what the thing is for.  In
    one case, we figured out that we were using up the equivalent of a
    full-time admin. asst. to manage production of a complex  a report that
    nobody used (except for 1 senior vice president who'd retired three
    years previous).
    
    Somebody ought to ammend documentation standards to require
    explanations of whyu thing were done the way they were.
    
    -dave

How come we're discussing software development here, rather than in CURIE::CASE?
(Not that I mind - it's nice to see some awareness of software in the
community).

This whole issue of (supposedly) quality versus time-to-deliver is as old as
the hills. Most of the questions around prototyping, performance, delivery
time and quality have been ground out over the years by the advocates and
opponents of fourth generation languages (4GLs). As is usually the case, a
dynamic equilibrium exists. Sure, there's a tradeoff between the different
values of responsiveness to user needs, time to market, robustness, ease
of modification, business benefits, cost of development, etc. In theory it's
just a problem in linear programming. The trouble is - who can quantify all
those variables, and whom will you trust to weight them correctly?

An example of what I mean: someone remarked that since productivity and the
number of programmers are both growing much slower than the demand for code,
we have a problem. Well, if code has to be written too fast, it won't work
very well, and this will incur costs of various kinds (from a few hundred
dollars through the company right up to corporate homicide charges). You can
get more programmers by offering incentives (better salaries, better training,
nicer offices, better locations, more respect) - I'm all in favour of this.
But theoretically all this can be worked out numerically and the market should
adjust. There are some "rigidities" though - such as managers who would rather
see the company fail than let a programmer be paid more than themselves.

The point about performance made in .24 is interesting in this context. A
company RADs a project quickly, then discovers it performs very poorly so
that you need batteries of mainframes to run it. So - if it is worth that
much to the company to have the application early, buy the mainframes! They
don't cost so much - a few million dollars, maybe. (ALL-IN-1 is an example
of this syndrome - many customers, especially governments and banks, don't
care if they have to spend $10 million for hardware instead of $2 million,
IF they get the application they want when they want it).

Always remember - "There Ain't No Such Thing As A Free Lunch!" Engineering is
the science of tradeoffs - hmmm, maybe not that much different from management
after all!

By the way, nobody has really defined "RAD" in this topic. We've said what its
benefits are, but not how they are obtained. This is a standard IBM approach
(c.f. their fabulous "repository", which has all the benefits and none of the
drawbacks of real software). Anyone care to offer some definitions?

From what I've heard, RAD falls under the classification of CASE anyway.
One recent and very popular type of CASE tool is the graphical analysis/design
tool (e.g. Teamwork, Excelerator, Software Through Pictures, Virtual Software
Factory, DECdesign). Some of these can generate code. Virtual Software Factory,
using the SSADM methodology, generates SQL (and thus databases and records and
fields and queries and...). Currently Digital offers Datatrieve, RALLY and the
COBOL Generator, all of which lend themselves to RAD.

Moreover, it is likely that the 4GL and CASE approaches may be pulled closer
together in the future. See the discussion of DECdesign in CLT::SDT and
CLT::ADGE for more details. If anyone has any practical suggestions or
requirements for the inclusion of business analysis features (similar to
Information Engineering or IBM's "IBSDM" in DECdesign) then try sending
them to Lance TPSYS::Simon, one of the DECdesign product managers. Or try
tabling them for discussion in CURIE::CASE or MEO78B::ANALYSIS_AND_DESIGN.

/Tom