Re: DoD and Reusability - Part 4

[creedy@cca.UUCP]

In article <8703241137.AA03138@ucbvax.Berkeley.EDU> Ed Berard writes:
>
> . . .
>
>   1. Current and future software standards and policies should be
>      explicitly examined for their impact on software reusability.
>      THIS IS A *TECHNICAL* ITEM. Merely placing such words as
>      "software reusability" in a standard or policy will not
>      guarantee sound reuse of software.   . . .

Absolutely!!

>   2. A "Software Reusability Plan" (SRP) should be a required part of
>      any contractor's software proposal.   . . .
>
>   3. Software contractors should also be required to produce a short
>      post-project assessment of the impact of sofware resue on their
>      project.  These assessments should be placed in the public domain 
>      whenever possible.

I believe (for personal philosophical reasons) that software reuse is
the only way that we can solve the crisis in software development.
Therefore, I agree with the concept here.  But ...

(FLAME ON)

I have seen a large number of programs out of the DoD where an almost
infinite variety of plans, documents and reviews were required of the
contractor.  A number of these projects failed because they took too
long, were too costly, or failed to adequately address the requirements.
In my personal experience, the failure probability of the project could
be correlated positively to the number of documents, reviews, etc. that
were called for.  I.e.  the more documents, etc. the more likely the
project was to fail.

I believe that the primary cause for this phenomenon is that the DoD
(and the government in general) does not take plans, documents, reviews,
etc.  seriously.  I have rarely seen the resources committed by the
government to adequately review, for example, the detailed design of the
software as a part of a CDR (Critical Design Review).  In many of these
cases, the reviews are a "dog and pony shows" that allow the government
program manager to impress his peers and supervisors with how well the
program is progressing.  In this environment, criticism of the program
is discouraged.  Further, the contractor usually knows that a real
review will not be held.  This allows the contractor to do work he knows
to be inadequate on the basis that he needs to make his milestones (in
order to get a good review from HIS supervisor) and can make up the work
later.  Unfortunately, coding (or whatever) comes after the review and
once the government has approved the design, the contractor MUST start
coding, leaving no time to return to complete the design.  Finally, (and
worst of all) in some cases the contractor doesn't know better and
assumes that because he has checked all the boxes and passed the review,
that he has in fact done an acceptable job.

Those projects that I have seen that have been successful have tended to
either:

(a) have the government take their role as reviewers of the project
seriously.  This requires a willingness (and budget) on the part of the
government program management to commit the resources necessary to do an
adequate review, and to understand that if contractor's work is
inadequate, that the program will have to be delayed and/or replanned,
but that it is better to do that now than deal with the inevitable
problems and delays that will arise later.  Or,

(b) have the government trust the contractor, save contract funds by
holding minimal reviews and requiring minimal documentation and make
sure that everyone understands that the contractor will be at fault if
the program fails.

(FLAME OFF)

Which is all to say ...

Before proposing yet another document that must be produced by
government software contractors, I believe you should consider whether
this document will be treated by the government (and therefore the
contractors) as another box of paper that must be provided by the
contractor and will be filed away and forgotten or whether it will be
taken seriously by the government's project management offices.

I offer the proposal that government procurement offices require that
program management offices provide (and make use of) resources and a
budget for adequately reviewing and critiquing the documents that are
produced by the contractors.  I personally believe that this would
provide more benefits in terms of the success of software projects than
all the additional ignored documentation that one might require the
contractor to produce.  

>Finally, to those of you who would rather see this mailing list used 
>as a forum solely for the discussion of the syntax and semantics of 
>the Ada language: thank you for your indulgence.  

Ditto.

Chris Reedy
Computer Corporation of America
Disclaimer:  My opinions are my own and not those of my employer.