RE: Two persons per product"

I think the blueprint analogy works in the opposite direction. Drafting is a
way of drawing a picture that illustrates (very precisely) a way of solving
a problem.  The conventions (electrical, mechanical, architechtural...) are
pretty strict, but they're like the syntax and reserved words of a
programming language.  In any given language we are constrained by the same
sort of standards in order that our programs compile.

Except at the very lowest level, most drafting is done by people who decide
how the problem is solved.

> -----Original Message-----
> From: Nathan M. Andelin [mailto:nandelin@relational-data.com]
> Sent: Monday, December 10, 2001 2:07 PM
> To: midrange-l@midrange.com
> Subject: Re: Two persons per product"
>
>
> From: "Leif Svalgaard" <leif@attglobal.net>
> > In order that the blueprints be understandable
> > and hence useful now and 20 years from now, there is
> > very little room for "creativity" and "personal style".
>
> If programming were standardized to the level of blueprints, then most
> programs would be produced by programs (code generators),
> similar to the way
> blueprints are produced by programs (computer aided
> drafting).  Relatively
> little human involvement.  Very little creativity.
>
> Fortunately our profession hasn't reached that point.  Nor do
> I think it
> will.
>
> Blueprints define a state.  Similar to the way a data
> structure defines a
> state.  There's not much room for creativity in that.  But,
> programs do much
> more than define state.  They also define a process.  Similar
> to the way a
> story defines a plot.
>
> > The pride in your work comes not from being
> > original but from executing your job in a professional
> > manner.
>
> While blueprint standards are rigid, and original expression
> is minimal, I
> don't find that particularly "professional".  Professionals are
> distinguished by the use of their brains, talents, and other
> resources of
> that may be available to solve unconventional problems.
>
> Is drafting considered more professional than architecture because in
> drafting, standards are more rigid?
>
> Creativity and original expression are also requirements of ownership
> (copyright law).  I don't see much value in minimizing their role.
>
> Hopefully these points don't detract too much from the
> original topic of
> teamwork, which is often a good approach to software development.
>
>
> Nathan M. Andelin
> www.relational-data.com
>
>
>