Subject: Re: open source process issue
From: "Jonathan S. Shapiro" <>
Date: Sun, 7 Oct 2001 19:38:02 -0400

> Because at the beginning of a small software project, it's not what
> counts. On any successful project, however, it is bound to be important
> sooner than later.

At the risk of violent agreement, a further thought:

Too much process too early can be just as destructive as too little process
too late. The process needs to evolve with the project, and the early team
needs to do its abbreviated process with recognition that it will later be
necessary to back-fill as the team bulks up and the product lifecycle starts
in for real.

We are going through this transition right now as we prepare EROS for
assurance evaluation, and I'm very very thankful that I earned my road rash
on previous projects and knew how to be prepared for this eventuality.

Actually, I'm co-teaching a course now on developing for high-assurance,
which (today) is by definition a tiger-process activity (because you can't
backpatch high assurance). One of the early discussions in the course
concerned (a) how big can your team be and still succeed and (b) what
process is appropriate for the optimal team size, given the downstream need
for evidentiary artifacts as input to the assurance process.

It is noteworthy that no team large enough to complete the nominal
requirements of the Common Criteria process in the advocated way has ever
succeeded in building a high-assurance system. Every example we have of
reasonably high-assurance systems was created first by experts, and the
design documentation was filled in later -- usually by culling the informal
mechanisms used by the original team (e.g. email archives of design