Re: chief programmer team organizations was (c++ vs ada results)

Re: chief programmer team organizations was (c++ vs ada results)

[Ralph Reid III]

In article <73164@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>. . .
>Please use comp.object or some other neutral forum to "discuss" the
>"relative advantages" of various programming languages.
>
>Please leave individual language forums such as comp.lang.c++ or
>comp.lang.ada open for people to ask questions about their individual
>languages and hopefully receive answers.
>
>Some of us have been reading comp.lang.c++ and/or comp.lang.ada and/or
>comp.lang.xyz for several years now, and have read literally dozens 
>of these inter-language "comparisons."  We have heard many of the same 
>"comparisons" made between the many of the same languages many times over.
>The only result has been that some of the most experienced programmers
>refuse to read or contribute to their particular language groups anymore,
>finding them too much of a waste of time.
>
>. . .

Yeah!  Some one wanna start a comp.lang.comp group?

-- 
Ralph.  N6BNO.
Compuserve - 72250.3521@compuserve.com.  Phone 1-916-345-9155.
lectromail- rreid@cscihp.ecst.csuchico.edu.
I do not waste time expressing others' opinions!

Re: chief programmer team organizations was (c++ vs ada results)

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!mstr!mstr!jcm]

In article <1991Jul04.144950.1570@ecst.csuchico.edu> rreid@ecst.csuchico.edu (R
alph Reid III) writes:
>In article <73164@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>. . .
>>Please use comp.object or some other neutral forum to "discuss" the
>>"relative advantages" of various programming languages.
>>
>>Please leave individual language forums such as comp.lang.c++ or
>>comp.lang.ada open for people to ask questions about their individual
>>languages and hopefully receive answers.
>>
>>Some of us have been reading comp.lang.c++ and/or comp.lang.ada and/or
>>comp.lang.xyz for several years now, and have read literally dozens 
>>of these inter-language "comparisons."  We have heard many of the same 
>>"comparisons" made between the many of the same languages many times over.
>>The only result has been that some of the most experienced programmers
>>refuse to read or contribute to their particular language groups anymore,
>>finding them too much of a waste of time.
>>
>>. . .
>
>Yeah!  Some one wanna start a comp.lang.comp group?
>
Well, comp.lang.misc already exists and seems the ideal forum.

>-- 
>Ralph.  N6BNO.
>Compuserve - 72250.3521@compuserve.com.  Phone 1-916-345-9155.
>lectromail- rreid@cscihp.ecst.csuchico.edu.
>I do not waste time expressing others' opinions!


-- Jim

*------------------------------------------------------------------------------
*
Jim McKim  (203)-548-2458   _Give_ people fish and they eat for a day.  
Internet:  jcm@mstr.hgc.edu _Teach_ people to fish and they eat for a lifetime.

Re: chief programmer team organizations was (c++ vs ada results)

[gdtltr@limbo.org (The Befuddled One)]

In article <3432@sparko.gwu.edu> mfeldman@seas.gwu.edu () writes:
=>In article <1991Jul3.014818.825@netcom.COM> jls@netcom.COM (Jim Showalter) wr
ites:
=>>Perhaps we should have comp.lang.C-is-the-best and comp.lang.C-bites,
=>>since those seem to be the two most common positions taken.
=>
=>I suggest alt.language.jihad.
=>
   Alternatively, there is always alt.religion.computers.

=>Mike

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration



-- 
                              duzan@cis.udel.edu
   _o_                        ------------------                          _o_
 [|o o|]       There must be more to life than just reading News.       [|o o|]
  |_o_|        Disclaimer: I have no idea what I am talking about.       |_o_|

Re: chief programmer team organizations was (c++ vs ada results)

[Michael Feldman]

In article <1991Jul3.014818.825@netcom.COM> jls@netcom.COM (Jim Showalter) writ
es:
>Perhaps we should have comp.lang.C-is-the-best and comp.lang.C-bites,
>since those seem to be the two most common positions taken.

I suggest alt.language.jihad.

Mike

Re: chief programmer team organizations was (c++ vs ada results)

[Michael Feldman]

In article <73164@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Please use comp.object or some other neutral forum to "discuss" the
>"relative advantages" of various programming languages.

Amen!
 
>Please leave individual language forums such as comp.lang.c++ or
>comp.lang.ada open for people to ask questions about their individual
>languages and hopefully receive answers.

Thank you for expressing this so well; I hope it works this time.
 
>These comparisons seem to do nothing to convince programmers to switch
>from their favorite language to another one.  Please then, can we
>try to leave the individual language forums open to discuss the
>individual languages, so that programmers programming in their favorite
>languages can at least be as informed and intelligent about that
>language as possible?


Every so often a little bit of comparative languages is good, for example to
explain a bit of Ada in terms of someone else's experience in Pascal, say
(as a comparative languages teacher I have foubd this usually to be helpful).
But the endless comparisons alternating with flames and sometimes degenerating
to ad hominem attacks gets to be boring and distasteful. I'll try to do
my part on this. Thanks again for posting it.

Mike
---------------------------------------------------------------------------
Prof. Michael Feldman
Department of Electrical Engineering and Computer Science
The George Washington University
Washington, DC 20052 U.S.A.

phone 202-994-5253
fax   202-994-5296
email mfeldman@seas.gwu.edu
---------------------------------------------------------------------------

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

jimad@microsoft.UUCP (Jim ADCOCK) writes:

>Please use comp.object or some other neutral forum to "discuss" the
>"relative advantages" of various programming languages.

Well, comp.object certainly isn't the forum--every time a language
comparison starts up there someone flames it too.

Perhaps we should have comp.lang.C-is-the-best and comp.lang.C-bites,
since those seem to be the two most common positions taken.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Jim ADCOCK]

In article <1991Jun25.193018.14571@zip.eecs.umich.edu> warack@dip.eecs.umich.ed
u (Christopher Warack) writes:
>In article <1991Jun25.183805.9549@netcom.COM> jls@netcom.COM (Jim Showalter) w
rites:
>>nagle@well.sf.ca.us (John Nagle) writes:
>>>jls@netcom.COM (Jim Showalter) writes:

Please use comp.object or some other neutral forum to "discuss" the
"relative advantages" of various programming languages.

Please leave individual language forums such as comp.lang.c++ or
comp.lang.ada open for people to ask questions about their individual
languages and hopefully receive answers.

Some of us have been reading comp.lang.c++ and/or comp.lang.ada and/or
comp.lang.xyz for several years now, and have read literally dozens 
of these inter-language "comparisons."  We have heard many of the same 
"comparisons" made between the many of the same languages many times over.
The only result has been that some of the most experienced programmers
refuse to read or contribute to their particular language groups anymore,
finding them too much of a waste of time.

These comparisons seem to do nothing to convince programmers to switch
from their favorite language to another one.  Please then, can we
try to leave the individual language forums open to discuss the
individual languages, so that programmers programming in their favorite
languages can at least be as informed and intelligent about that
language as possible?

Re: chief programmer team organizations was (c++ vs ada results)

[Chuck Shotton]

In article <1991Jun26.005625.25608@netcom.COM>, jls@netcom.COM (Jim Showalter) writes:
> If everyone tries to design the architecture, the result is not an
> architecture at all--it is a camel. Design by committee is generally
> regarded as a bad idea, yet you seem to be advocating a really big
> committee in your post. Or am I just confused?
> 
The point I was trying to make is that the concept of an Ada "coder" is antiquated.
Once upon a time, when designer could draw flow charts and make entries on
coding sheets, it was easy for the worker drones to turn that info into Cobol
or Fortran. A "coder" has clerical, mundane, non-creative connotations. Basically,
it's someone who takes someone else's ideas and turns them into syntactically
correct code. 

My point is that this concept of a few people PRESUMING to understand all
the intricacies of a system and mandating design decisions to a group of "coders"
is out of date. It's the "aerospace way," and is probably the single biggest
reason why there is a crisis in engineering and delivering large systems.

When working on "mega" systems (500K+ SLOCs), no handful of humans can keep
it all straight. I can't begin to count the number of times where Joe Coder
has had a totally novel idea that made huge differences in the architecture
as engineered by a few "Chief Programmers".

I'm not advocating design by committee by any stretch of the imagination.
Design by consensus, yes! My experience has shown that EVERY time there is
contention or disagreement during the design process, it is because of only
2 reasons. 1) Existing design Ideas are not being effectively communicated, 
or 2) Someone actually has a better idea. In the first case, I want to make
sure everyone on the team UNDERSTANDS the system, so I want everyone to have
input during the design process. This input is a measure of their level of
understanding. In the second case, I certainly don't want to overlook a better
approach by relegating a talented individual to a role of Ada coder.

I am certainly NOT advocationg a totally egalitarian approach to design and
implementation. That would presume that all designers/developers are equally
talented in all aspects of the job. I was very careful to point out that MANAGEMENT
must accept the responsibility for determining the level to which each individual
can contribute and allow them to do so.

This approach falls somewhere between "chief programmer" teams, and hacker
approaches to problem solving. The value lies in creating a team environment
where everyone is allowed to contribute in a constructive fashion to the design
and architecture of the final system. Notice I said "contribute." That doesn't
imply that all contributions are equally valid, nor must all contributions
be accomodated. It only implies that contributions must be allowed. Someone
must have the final decision as to what stays or goes.

Given that Ada lends itself well to decomposition that often follows the CSCI
decomposition of a system, it allows an organization to mirror the architecture
and people can contribute at the level they are comfortable with and responsible
for.

If people feel they are part of the process, you're more likely to receive
their maximum effort. The result being a quality product that is somewhat
better than "good enough." In an industry (DoD contracting) where there is
little to no incentive (eg. cost plus contracts) to do an on-time, above-average
job, every little bit helps.

This is sort of a religous subject, and it certainly has a lot to do with
management styles. I prefer to treat all individuals in a team environment as
equals until they prove otherwise. (This give MY managers major heartburn...)
Many people in this business see programmers as commodities to be tossed at
a problem (billing hours, all the while). These are the people that still
subscribe to the mythical man month. Type A, Theory X, call it what you will.
It manifests itself in all its glory on "Chief Programmer" tasks.

-----------------------------------------------------------------------
Chuck Shotton                 Internet:  cshotton@girch1.med.uth.tmc.edu
BIAP Systems                  UUCP:      ...!buster!brain!chuck
"Your silly quote here."      AppleLink: D1683       MacNet: shotton

chief programmer team organizations was (c++ vs ada results)

[John McHugh]

The seminal reference on CPTs is:

@Article[Bakertimes,
      Author=<Baker, F. T.>,
      Journal=<IBM Systems Journal>,
      key=<Baker>,
      Title=<Chief Programmer Team Management of Production Programming>,
      Year=<1972>,
      Volume=<11>,
      Number=<1>
]

This provides a more detailed exposition than is given in chapter 3 of
Brooks.  There were a number of other articles and reports during the
1970s.  I used the CPT organization for several programming projects
at NOAA during the early 70's and found it successful when a team with
the proper skills mix could be put together.

John McHugh
Visiting Associate Professor
Department of Computer Science
The University of North Carolina
Chapel Hill, NC, 27599-3175

Voice (919) 962-1826
Fax   (919) 962-1799
Email mchugh@cs.unc.edu

Re: chief programmer team organizations was (c++ vs ada results)

[Chuck Shotton]

In article <1107.286584f0@vger.nsu.edu>, g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) writes:
> Do chief programmer teams really work anywhere outside of a university
> classroom or in an experimental industrial setting?  
> 
> 
Approaches to running large scale development efforts appear to run the full
spectrum from totally autonomous hacker collectives to dictatorial chief 
programmer authoritarian states. From practical experience, I can relate you
a few success stories on some MEDIUM-sized (20-50 member teams) development
efforts.

An approach that seems to work well (with Ada) on data and user oriented
application code tasks is this. First, and foremost, all members of the development
team need to feel that they can make a constructive contribution to the DESIGN
as well as the more mundane coding effort. This has the effect of getting
everyone "signed up" to the grand vision of the system. All the programmers,
designers, and systems engineers have some stake in the quality of the final
product, because they are allowed to participate throughout the entire life
cycle. The concept of an "elite" design team dictating system architectures
to a "serf" class of coders is offensive to all but the most uncreative of
Ada programmers.

Before I get flamed to death, let me point out that on the tasks I've managed,
programmed on, or designed, it was VERY important for management to be fully
aware of the individual talents of each programmer. Then, structure the team
in such a way that each (productive) member of the team can make a constructive
contribution to the level of their abilities. Practical experience has also
shown that most managers don't show the slightest inclination towards doing
this.

On the SSE project, our most successful development efforts involved
teams of designer/developers who had cradle to grave involvement with the
software's life cycle. Every task that got in trouble or resulted in a less
than optimal solution was characterized by a few individuals mandating design
decisions on a staff of talented (and ultimately, resentful) developers. These
"problem" tasks also had serious trouble achieving a common vision of the
final system. The moral of the story seems to be: Where practical, allow the
greatest possible involvement in analysis and design activities by the people
who are ultimately going to code the system.

Not only is everyone "signed up" to the vision, but you end up educating a
bunch of developers to be something more than code slaves in a body shop.

[I have NO idea what this message has to do with comp.lang.ada, other than
the fact that all of this "experience" was gleaned from Ada development tasks.]

-----------------------------------------------------------------------
Chuck Shotton                 Internet:  cshotton@girch1.med.uth.tmc.edu
                              UUCP:      ...!buster!brain!chuck
"Your silly quote here."      AppleLink: D1683       MacNet: shotton

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>The concept of an "elite" design team dictating system architectures
>to a "serf" class of coders is offensive to all but the most uncreative of
>Ada programmers.

I may be misunderstanding your post, but from what I'm able to glean from
it, you don't think hierarchical decision making works on a project, and
that the alternative is a sort of enlightened egalitarianism. If so, I
disagree, based on my own experience. One does not expect bricklayers,
welders, pipefitters, etc to also design a skyscraper, any more than one
expects an architect to wire the offices. This always seems to get cast
into a class-vs-class struggle, when in fact it is a simple matter of
specialization and expertise. Not everyone can be an architect. On the
other hand, not everyone can be a bricklayer (believe me--it's harder
than it looks!). You reflect your own bias in the above quote, where
the subtext appears to be that coding is an uncreative pursuit. Therein
lies the error--coding is no more or less creative, no more or less
rewarding, than architecting, plumbing, needlepoint, or any other human
pursuit.

If everyone tries to design the architecture, the result is not an
architecture at all--it is a camel. Design by committee is generally
regarded as a bad idea, yet you seem to be advocating a really big
committee in your post. Or am I just confused?
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Orville R. Weyrich]

In article <1991Jun26.005625.25608@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>>The concept of an "elite" design team dictating system architectures
>>to a "serf" class of coders is offensive to all but the most uncreative of
>>Ada programmers.
>
>I may be misunderstanding your post, but from what I'm able to glean from
>it, you don't think hierarchical decision making works on a project, and
>that the alternative is a sort of enlightened egalitarianism. If so, I
>disagree, based on my own experience. One does not expect bricklayers,
>welders, pipefitters, etc to also design a skyscraper, 

Agreed.

>any more than one
But if I were a brick-layer, I would expect that there would be a suggestion
box around somewhere for my input -- sometimes field observations are useful
in catching oversights committed by the 'big boys'. Even better, the 'big
boys' would practice "management by walking around."

>expects an architect to wire the offices. This always seems to get cast

Agreed. Also, it would not be cost effective.

But I would be worried if the architect had no idea how to wire an office.



--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

Re: chief programmer team organizations was (c++ vs ada results)

[David M Geary]

]> Who knows?
] Jim Showalter

]>The concept of an "elite" design team dictating system architectures
]>to a "serf" class of coders is offensive to all but the most uncreative of
]>Ada programmers.
]
]I may be misunderstanding your post, but from what I'm able to glean from
]it, you don't think hierarchical decision making works on a project, and
]that the alternative is a sort of enlightened egalitarianism. If so, I
]disagree, based on my own experience. One does not expect bricklayers,
]welders, pipefitters, etc to also design a skyscraper, any more than one
]expects an architect to wire the offices. This always seems to get cast
]
]If everyone tries to design the architecture, the result is not an
]architecture at all--it is a camel. Design by committee is generally
]regarded as a bad idea, yet you seem to be advocating a really big
]committee in your post. Or am I just confused?

  I believe that the ones writing the actual code should be the ones
  that *architect the code they are writing*.

  We have GUI, client, and server software for accessing
  (ultimately), Oracle over a network.  We have 3 main guys
  responsible for GUI, client, and server respectively.  Each
  developer designs (architects, if you will) his respective system
  (GUI, client, or server).  Each developer writes the code to
  implement the design.  Each developer also has a "sidekick" who
  understands the system, and helps out from time to time writing
  functions, porting code, etc.

  Of course, there is data constantly flowing between the GUI,
  client and server.  Therefore, architectural decisions concerning
  interfaces between the 3 systems are decided by committee.

  I like the idea of having a small group (possibly 1) of developers
  responsible for a small subsystem.  The requirements for the
  subsystem are decided by implementors.  The design and coding for
  the subsystem are totally up to the group of developers.  When the
  subsystems interact, the issues are decided upon via committee,
  with those directly responsible for the subsystems which have to
  interact having the ultimate say in the design decision.

  To me, this falls in line with OOP mentality.  When one writes
  modular, reusable code, a class is defined with a specific
  interface.  For instance one may have a class point, with an
  interface consisting of point_Create(), point_Destroy(),
  point_GetX(), point_GetY(), point_Move(), etc.  How the point
  class *implements* this interface is nobody's business but the
  author of the class.  The same thing can be applied to subsystems
  in a software system.

  In summary, then:

  1. Break the system down into subsystems.

  2. Assign small teams to each subsystem.

  3. Teams are responsible for design/development of subsystem.

  4 .Interfaces between subsystems are designed by the developers of
     the subsystems involved.

  Now, it may be that in a very large project, there are so many
  subsystems that those dealing with the subsystems at the bottom
  cannot see the light of day.  In such a case, one may have system
  architects who *work with* the developers of the subsystems, to
  help design interaction between the subsystems.

  However, to have one group design, and then hand the entire design
  over to a group of "coders", I think, is asking for trouble.
  Communication alone between the designers and the coders leaves
  enough room for error to make me mighty nervous.

-- 
|~~~~~~~~~~       David Geary, Boeing Aerospace, Seattle, WA.       ~~~~~~~~~~|
|-----------------------------------------------------------------------------|
|~~~~~~  Seattle:  America's most attractive city... to the *jetstream* ~~~~~~|
|-----------------------------------------------------------------------------|

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

dmg@ssc-vax (David M Geary) writes:

>  I believe that the ones writing the actual code should be the ones
>  that *architect the code they are writing*.

No argument. Never said otherwise. BUT, the interactions between their
code and the other code in the system is at a higher level of abstraction.
An architect designs the superstructure for a skyscraper. The electricians
called into wire the offices on the 56th floor may well decide among 
themselves how their going to accomplish this, but they have to do so
within the OVERALL constraints as designed by the architect. For example,
they have to wire it in 110v/60Hz--this is an architectural decision about
how the 56th floor interfaces to other floors and to the outside world.
The electricians should NOT take it upon themselves to make a change to
this particular constraint, lest fires break out, sparks fly, etc.

>  We have GUI, client, and server software for accessing
>  (ultimately), Oracle over a network.

That's an architecture. Who thought it up? Who owns it?

>  Of course, there is data constantly flowing between the GUI,
>  client and server.  Therefore, architectural decisions concerning
>  interfaces between the 3 systems are decided by committee.

Ah! Now, is everybody on the team also on this committee? If so, you
either have a very large committee or a very small team. If, on the
other hand, this committee is a small portion of the total team,
then this is exactly the sort of architectural decision making by
a small group of experts I've been extolling the virtues of all
along.

>  1. Break the system down into subsystems.
>  2. Assign small teams to each subsystem.
>  3. Teams are responsible for design/development of subsystem.
>  4 .Interfaces between subsystems are designed by the developers of
>     the subsystems involved.

I think we're in violent agreement on all points except possibly #4.
I believe you want these decisions made by a very few people--if you
have 50 subsystems (big systems have this many or more), then you
either have a 50 person committee or you wind up with some architects
who are responsible for the grand vision (yes, they're supposed to
listen to what the developers have to say--they'd be idiots not to).

I think 99% of this entire thread has been more a problem of nomenclature
than of fundamental disagreement.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[David M Geary]

]  Jim Showalter
]> David Geary

]>  1. Break the system down into subsystems.
]>  2. Assign small teams to each subsystem.
]>  3. Teams are responsible for design/development of subsystem.
]>  4 .Interfaces between subsystems are designed by the developers of
]>     the subsystems involved.
]
] I think we're in violent agreement on all points except possibly #4.
] I believe you want these decisions made by a very few people--if you
] have 50 subsystems (big systems have this many or more), then you
                                                           ^^^^^^^^
] either have a 50 person committee or you wind up with some architects
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
] who are responsible for the grand vision (yes, they're supposed to
] listen to what the developers have to say--they'd be idiots not to).
]
  Well, you may have 50 people who, at one time or another, will
  make contributions/decisions on the committee, but I don't think
  you will hardly ever have all 50 people contributing at once.
  When making a decision concerning architecture of the system, you
  only have developers whose subsystems are directly effected making
  decisions...

] I think 99% of this entire thread has been more a problem of nomenclature
] than of fundamental disagreement.

  Yeah, probably so, but I think most people perceived that you
  meant there would be an "elite" group of designers who turned the
  design over to a "non-elite" group of developers to "code".  While
  this was probably not what you meant, it nonetheless has hit a
  nerve.

-- 
|~~~~~~~~~~       David Geary, Boeing Aerospace, Seattle, WA.       ~~~~~~~~~~|
|-----------------------------------------------------------------------------|
|~~~~~~  Seattle:  America's most attractive city... to the *jetstream* ~~~~~~|
|-----------------------------------------------------------------------------|

Re: chief programmer team organizations was (c++ vs ada results)

[Dan Weinreb]

In article <1991Jun26.005625.25608@netcom.COM> jls@netcom.COM (Jim Showalter) writes:

   >The concept of an "elite" design team dictating system architectures
   >to a "serf" class of coders is offensive to all but the most uncreative of
   >Ada programmers.

   If everyone tries to design the architecture, the result is not an
   architecture at all--it is a camel.

He did not say that everyone tries to design the architecture.  He said,
and I quote,


				  First, and foremost, all members of the development
  team need to feel that they can make a constructive contribution to the DESIGN
  as well as the more mundane coding effort. This has the effect of getting
  everyone "signed up" to the grand vision of the system. All the programmers,
  designers, and systems engineers have some stake in the quality of the final
  product, because they are allowed to participate throughout the entire life
  cycle. The concept of an "elite" design team dictating system architectures
  to a "serf" class of coders is offensive to all but the most uncreative of
  Ada programmers.

Please note the use of the phrase "constructive contribution" and the
phrase "some stake" and the phrase "signed up".  He did not say that
everybody writes one paragraph of the design document.  He did not say
that everybody has to contribute equally, or that nobody is more
influential than anyone else.  

As I said in a previous posting, the interaction between people on a
project is a human social interaction, and as such is complex and
subtle.  It can't be reduced to simple formulas.  Many goals must be
taken into account, and many things must be balanced against other
things.  I agree strongly with Chuck Shotton's original posting, but I
don't think it conflicts with the idea that in any project involving
many people, it will be possible to identify a smaller subset of key
architects.  However, the meaning of "architect" isn't as simple as
"anybody who isn't an Architect is locked out of the room when the
Design is being Formulated, and the design, Fully Formed and Cast in
Concrete, is handed to him for execution."  In other words, progrmmers
aren't separated into two hard-and-fast groups; it's a matter of degree.
In my experience, that's the best way to organize a software project.

Re: c++ vs ada results

[Mats Henricson]

jls@netcom.COM (Jim Showalter) writes:

>[I've cut the newsgroups down to a reasonable number.]

>>>>o	C++ is hard to master.
>>>Indeed. Note that this contradicts the claim made earlier that C++ is
>>>easy to learn.

>>You are truly showing your foolishness here.  Most people out of grade
>>school realize there is a difference between "learning" something and
>>"mastering" it.  I guess you're just special, aren't you?

>The person I was responding to was talking about the difficulty of
>learning to write good programs in C++. He chose the term "master"
>to denote this. I chose the term "learn" to denote this same idea.
>Why this warranted a personal attack is beyond me, particularly
>since you seem to have not taken issue with the key point of the
>exchange, namely that getting good at writing programs in C++ is hard
>to do.

I have started to see two different kinds of programmers in C++:
1. Library designers
2. Library users

The first kind of programmers is doing some tricky nasty hacking behind the
scenes of the interface of the classes, to satisfy the second kind of users.

I have so far only done programming as a library designer, and I think that
is *VERY* difficult if you try to produce code that is:
a) fast
b) not wasting memory
c) usable
d) reusable (in terms of subclasses)
e) etc
f) etc
g) etc

If you, on the other hand, have a well designed class library to build from,
I think C++ is a beautiful and easy language to use.

Mats Henricson, Sweden

Re: c++ vs ada results

[Jim Showalter]

>I have started to see two different kinds of programmers in C++:
>1. Library designers
>2. Library users

>The first kind of programmers is doing some tricky nasty hacking behind the
>scenes of the interface of the classes, to satisfy the second kind of users.

>I have so far only done programming as a library designer, and I think that
>is *VERY* difficult
 if you try to produce code that is:
>a) fast
>b) not wasting memory
>c) usable
>d) reusable (in terms of subclasses)
>e) etc
>f) etc
>g) etc

>If you, on the other hand, have a well designed class library to build from,
>I think C++ is a beautiful and easy language to use.

This is an excellent point, and mirrors my own experiences with Ada. I imagine
similar things are true of Eiffel, Modula-3, and any of the other modern
software engineering languages. There is nothing WRONG with this, but an
organization needs to recognize that with increased language complexity comes
a greatly increased ability for the average programmer to get in trouble.
It is against the hacker credo of universal egalitarianism to admit this,
but the simple truth is that some people are qualified to be architects
and some are not--and handing power tools to people only qualified to
hammer nails results both in poor construction and arterial bleeding.

One of the most successful Ada projects I'm aware of organized job
descriptions and responsibilities in such a way that a relatively small
number of exceptionally clever people was responsible for the architecture
(as captured in subsystem decomposition and subsystem interface specification),
each subsystem had a talented lead in charge of its implementation (but could
not alter the interfaces, which required an architectural decision), and
within each subsystem there was a team consisting of designers and programmers
(the designers designed package specs [class headers] and the programmers
implemented the bodies). It worked great...and one of the nicest things
about it was that it took the pressure OFF the folks who just wanted to
go program so that they didn't have to PRETEND to be architects. Nobody
felt insulted. Best of all, the staffing requirements when jobs are
set up this way are such that the availability of people is inversely
proportional to the expertise required--the less a person needs to know,
the more of them you hire, making it pretty simple to get the team
assembled (one or two hard-to-find architects, a small group of leads,
a bunch of programmers [many of them entry level and just starting to
learn the Ada language]).
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: c++ vs ada results

[Doug Smith]

In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
> One of the most successful Ada projects I'm aware of organized job
> descriptions and responsibilities in such a way that a relatively small
> number of exceptionally clever people was responsible for the architecture
> (as captured in subsystem decomposition and subsystem interface specification),
> each subsystem had a talented lead in charge of its implementation (but could
> not alter the interfaces, which required an architectural decision), and
> within each subsystem there was a team consisting of designers and programmers
> (the designers designed package specs [class headers] and the programmers
> implemented the bodies). It worked great...and one of the nicest things
> about it was that it took the pressure OFF the folks who just wanted to
> go program so that they didn't have to PRETEND to be architects. Nobody
> felt insulted. Best of all, the staffing requirements when jobs are
> set up this way are such that the availability of people is inversely
> proportional to the expertise required--the less a person needs to know,
> the more of them you hire, making it pretty simple to get the team
> assembled (one or two hard-to-find architects, a small group of leads,
> a bunch of programmers [many of them entry level and just starting to
> learn the Ada language]).

The simplest follow-up I have ever done.  Thank you, Mr. Showalter for
having also described two of the Ada projects I have worked on.  They
were on-schedule and produced products that satisfied requirements while
achieving a level of quality well above what was needed.

Re: chief programmer team organizations was (c++ vs ada results)

[Alex Blakemore]

In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
> One of the most successful Ada projects I'm aware of organized job
> descriptions and responsibilities in such a way that a relatively small
> number of exceptionally clever people was responsible for the architecture
> (as captured in subsystem decomposition and subsystem interface specification),
> each subsystem had a talented lead in charge of its implementation (but could
> not alter the interfaces, which required an architectural decision), and
> within each subsystem there was a team consisting of designers and programmers
> (the designers designed package specs [class headers] and the programmers
> implemented the bodies). It worked great...and one of the nicest things
> about it was that it took the pressure OFF the folks who just wanted to
> go program so that they didn't have to PRETEND to be architects. Nobody
> felt insulted. Best of all, the staffing requirements when jobs are
> set up this way are such that the availability of people is inversely
> proportional to the expertise required--the less a person needs to know,
> the more of them you hire, making it pretty simple to get the team
> assembled (one or two hard-to-find architects, a small group of leads,
> a bunch of programmers [many of them entry level and just starting to
> learn the Ada language]).

This makes sense and sounds like it can work well. It's really just
the chief programmer teams from the Mythical Man Month by Fred Brookes.
One obvious caveat - you really better have the right people
in the chief programmer roles or you are sunk.  This organization
alone is not sufficient.  I've been on projects at previous jobs with
such setups and the upper roles were assigned to those that had been
hired earlier, which wasn't the ideal criteria in my mind. They tended to
restrict the flow of information between team members, which was great when
they were able to create well designed independent work packages - but
was a real hindrance when there were problems.  

  I knew one very bright programmer who had unworkable designs pressed on
him by the leader of his subgroup.  He couldnt totally redesign it without 
her fighting every step of the way, even though it was absolutely necessary.  
He finally resorted to making the redesign but leaving a few obvious simple 
flaws that even she could detect, presenting the design to her for review 
and asking her help in solving those last sticky "problems".  She saved 
her ego, the software was corrected but the poor guy at the bottom had to 
suffer through this several times and the lead got the credit when it worked.
He would have done better to let the project fail if his goal was to advance in
the organization.  This project structure is not very forgiving if you place
people too high or low in the hierarchy.

If you are interested in a biting but accurate satirical treatise on
the role of incompetance and hierarchies in large organizations, see the
classic book - "The Peter Principle".




-- 
---------------------------------------------------------------------
Alex Blakemore           blakemore@software.org        (703) 742-7125
Software Productivity Consortium  2214 Rock Hill Rd, Herndon VA 22070

Re: chief programmer team organizations was (c++ vs ada results)

[Lars P. Fischer]

>>>>> On 20 Jun 91, blakemor@software.software.org (Alex Blakemore) said:

Alex> This makes sense and sounds like it can work well. It's really just
Alex> the chief programmer teams from the Mythical Man Month by Fred Brookes.
Alex> One obvious caveat - you really better have the right people
Alex> in the chief programmer roles or you are sunk.

Please note that the Brookes book is not exactly new -- it's a great
book, one that every serious software professional should read, but
remember that some of the advise reflects state-of-the-art in the
early 70's.

I recommend DeMarco's "PeopleWare" book as a good introduction to the
management of development and the organization of people and teams. It
reflects a more modern approach to providing teams with a good spirit
by giving each person responsibility and the opportunity to develop,
plus providing good working environments. This is much more in line
with modern management practice.

Alex> If you are interested in a biting but accurate satirical treatise on
Alex> the role of incompetance and hierarchies in large organizations, see the
Alex> classic book - "The Peter Principle".

And please, please, remember that Parkinson's books are just that -
satire. They were never intended to be textbooks or solid advise on
management. They are hilariously funny and thought provoking at the
same time, but taking them literally would be a mistake.

/Lars
--
Lars Fischer,  fischer@iesd.auc.dk   | It takes an uncommon mind to think of
CS Dept., Univ. of Aalborg, DENMARK. | these things.  -- Calvin

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>Alex> If you are interested in a biting but accurate satirical treatise on
>Alex> the role of incompetance and hierarchies in large organizations, see the
>Alex> classic book - "The Peter Principle".

>And please, please, remember that Parkinson's books are just that -
>satire. They were never intended to be textbooks or solid advise on
>management. They are hilariously funny and thought provoking at the
>same time, but taking them literally would be a mistake.

Uh, you might want to check with Mr. Peter on that--I believe he was
quite serious. And I've certainly seen the principle he elucidates in
action in the real world (think of Dan Quayle...).
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Hargrove]

>>>>> fischer@iesd.auc.dk (Lars P. Fischer) writes:


>>>>> On 20 Jun 91, blakemor@software.software.org (Alex Blakemore) said:


Alex> If you are interested in a biting but accurate satirical treatise on
Alex> the role of incompetance and hierarchies in large organizations, see the
Alex> classic book - "The Peter Principle".

Lars> And please, please, remember that Parkinson's books are just that -
Lars> satire. They were never intended to be textbooks or solid advise on
Lars> management. They are hilariously funny and thought provoking at the
Lars> same time, but taking them literally would be a mistake.

Well, maybe not. I notice that you are in academia. I find the Peter
Principle works pretty well in BIG BUSINESS. BTW, the book was written
by Lawrence(?) Peter, not Parkinson. On the other hand, Parkinson's
laws seem to be VERY relevant to the real world. Work really does
expand to fill time available. Extensions to disk space are also valid.
-- 

        -- jwh

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>He finally resorted to making the redesign but leaving a few obvious simple 
>flaws that even she could detect, presenting the design to her for review 
>and asking her help in solving those last sticky "problems".  She saved 
>her ego, the software was corrected but the poor guy at the bottom had to 
>suffer through this several times and the lead got the credit when it worked.
>He would have done better to let the project fail if his goal was to advance in
>the organization.  This project structure is not very forgiving if you place
>people too high or low in the hierarchy.

"Against stupidity, the gods themselves contend in vain." Sadly, this
sounds like a fairly typical project. I swear, when I get in a bad mood
I half believe the single most effective solution to what ails most
troubled software development efforts would be to simply shoot every
third manager. Arghh.

On the other hand, the project I described in my earlier post was
QUITE atypical. They chose Ada on its merits (didn't have to use it--just
evaluated what was available and decided Ada was the only viable tool
for solving their problem). They had a superb chief architect. They
knew they were building 4 ships in a row, so they focused on reuse from
the start as a MULTI-project objective (achieving, in the end, 70% reuse
across the four projects and $117 million in savings [their numbers]).
They made optimal use of Rational's technology. They were just wonderful.
It's projects like this that make it all worthwhile...just wish there
were more like it.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[John Nagle]

     Real chief programmer teams are very rare.  I've never heard of one
other than in Brooks' book.  It's very different than having a lead programmer
or a system architect.  It's organized like a surgical team.  The chief
programmer personally writes most of the delivered code, and everything else
is set up to facilitate this.  There is an administrator, who reports to the
chief programmer, to take care of mundane problems.  A toolsmith creates
tools not part of the deliverable code.  A language lawyer deals with
compiler and library issues.  A tester tests everything.  A librarian 
keeps track of everything.  All these people are subordinate to the chief
programmer.

    It's too much of a culture shock for most organization.

					John Nagle
    

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>     Real chief programmer teams are very rare. I've never heard of one
>other than in Brooks' book.

Given your description below, I don't find this surprising, since I
find it impossible. Read on.

>It's organized like a surgical team.  The chief
>programmer personally writes most of the delivered code, and everything else
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>is set up to facilitate this.

Tommyrot! How on earth is a single human being going to write "most",
or, for that matter, even a FRACTION, of the code on a project of
significant size? I'm talking here of things like the multi-MILLION
line FAA rewrite of the U.S. air traffic control system. No, what is
needed is a single architect (or at least a very small number of
architects on a tightly focused team) who set up the groundrules for
the overall system. After that, a horde of implementors can hammer
out the individual subsystems.

What you describe sounds like something that MIGHT work, but only on
a programming-in-the-small project, which I'm not particularly interested
in (I view programming-in-the-small as a solved problem).

>    It's too much of a culture shock for most organization.

As would be any unworkable scheme. ;-)
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[David Feustel]

I think the FAA project will never be finished (except by decree).
-- 
David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631
EMAIL: feustel@netcom.com  or feustel@cvax.ipfw.indiana.edu

I voted for Bush once.  As it's turning out, once was once too often.

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>I think the FAA project will never be finished (except by decree).

Why? I was involved with that project, and they're basically on schedule
and have written gazillions of lines of stuff that works, and are
continuing to write more. What insight into that project do you have
that I do not?
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Dan Weinreb]

In article <1991Jun23.185449.24818@netcom.COM> jls@netcom.COM (Jim Showalter) writes:

   >I think the FAA project will never be finished (except by decree).

   Why? I was involved with that project, and they're basically on schedule
   and have written gazillions of lines of stuff that works, and are
   continuing to write more. What insight into that project do you have
   that I do not?

"No software is ever finished until the last user is dead."
   -- Old Canturbridian Proverb

Re: chief programmer team organizations was (c++ vs ada results)

[Marco S Hyman]

In article <1991Jun23.032353.8718@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
 > Tommyrot! How on earth is a single human being going to write "most",
 > or, for that matter, even a FRACTION, of the code on a project of
 > significant size? I'm talking here of things like the multi-MILLION
 > line FAA rewrite of the U.S. air traffic control system.

If one can imagine the system then one can build the system, just a little
slower than two, or three.  But in any case faster than 100.  Every new person
adds to the communications burden and increases the chance of a
mis-communication causing something to be misunderstood.  Misunderstandings
lead to defects and system failures.  I'd guess seven would be the top end,
providing you have the right seven.  Three seems to be a good number in
practice.

Charles Moore once said at a conference (I think it was Software Development
'89) that he'd have no problem with SDI providing he was the one writing the
software.  (In forth?)  And yes, I was involved in a project where three
re-designed and wrote a system originally done by a group of 20 -- faster,
with less problems, to the customers greater satisfaction, etc.

And how many lines of code is TeX, Metafont, etc.  Do you count the
documentation?  But size isn't the issue here.  Quality is.  If the
customer wants it bad, that's how he's going to get it.

// marc
-- 
// home: marc@dumbcat.sf.ca.us		pacbell!dumbcat!marc
// work: marc@ascend.com		uunet!aria!marc

Re: chief programmer team organizations was (c++ vs ada results)

[Stanley Friesen]

In article <1066@dumbcat.sf.ca.us> marc@dumbcat.sf.ca.us (Marco S Hyman) writes:
>If one can imagine the system then one can build the system, just a little
>slower than two, or three.  But in any case faster than 100.  Every new person
>adds to the communications burden and increases the chance of a
>mis-communication causing something to be misunderstood.  Misunderstandings
>lead to defects and system failures.  I'd guess seven would be the top end,
>providing you have the right seven.  Three seems to be a good number in
>practice.

This certainly fits with my experience.

A few years ago I was working on a 'large' project (for another company).
We had a team of about 10-12 programmers on the project for most of its
run.  When we finally quit, 2 years behaind schedule, we had a system
that didn't really work, was almost unmaintainable and had at least twice
the code necessary to do the job.

If the team had been reduced to the three (or four) best programmers the
project would have been done, nearly on time, and certainly in a usable
form.  The additional 7-8 people just slowed it down (and reduced quality).
[This was an extreme case, and there were other problems - like changing
specs, but the man-power bloat just amplified the problems]
-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

>>I'd guess seven would be the top end,
>>providing you have the right seven.  Three seems to be a good number in
>>practice.

>This certainly fits with my experience.

>A few years ago I was working on a 'large' project (for another company).
>We had a team of about 10-12 programmers on the project for most of its
>run.  When we finally quit, 2 years behaind schedule, we had a system
>that didn't really work, was almost unmaintainable and had at least twice
>the code necessary to do the job.

Please define 'large'. This whole discussion hinges on what that term
means to various people.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

> > Tommyrot! How on earth is a single human being going to write "most",
> > or, for that matter, even a FRACTION, of the code on a project of
> > significant size? I'm talking here of things like the multi-MILLION
> > line FAA rewrite of the U.S. air traffic control system.

>If one can imagine the system then one can build the system, just a little
>slower than two, or three.

Look, this is just silly. Back of the envelope, I get 1MSLOC as something
like 4 million words to type (this is probably much too low, but let's
assume few comments and few identifiers per line), which, for a
60 wpm typist works out to 6 months of just TYPING. No thought, no design,
no documentation, no debugging, no test, no integration. Just six months
to TYPE that much code. How long do you think it would take for one human
being to actually write real code of that size? 20 years? How much code
have you written in your lifetime, in aggregate? What's the most working
documented code you've seen a single human being crank out in a year?

Modern software projects cannot be written by one person unless the
customer is willing to wait 20-40 years for delivery.

>Every new person
>adds to the communications burden and increases the chance of a
>mis-communication causing something to be misunderstood.  Misunderstandings
>lead to defects and system failures.  I'd guess seven would be the top end,
>providing you have the right seven.  Three seems to be a good number in
>practice.

This is the Mythical Man Month and all that, but it is not necessarily
true. The trick is to divide up the project into chunks (I call them
subsystems) that themselves CAN be implemented by small teams, and to
formally enforce the interfaces between the chunks. The trick then
becomes for an architect to know where to make the slices.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[John Nagle]

jls@netcom.COM (Jim Showalter) writes:

>>     Real chief programmer teams are very rare. I've never heard of one
>>other than in Brooks' book.

>Given your description below, I don't find this surprising, since I
>find it impossible. Read on.

>>It's organized like a surgical team.  The chief
>>programmer personally writes most of the delivered code, and everything else
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>is set up to facilitate this.

>Tommyrot! How on earth is a single human being going to write "most",
>or, for that matter, even a FRACTION, of the code on a project of
>significant size? I'm talking here of things like the multi-MILLION
>line FAA rewrite of the U.S. air traffic control system. No, what is
>needed is a single architect (or at least a very small number of
>architects on a tightly focused team) who set up the groundrules for
>the overall system. After that, a horde of implementors can hammer
>out the individual subsystems.

      There's a school of thought that if you're writing something that big,
your approach is wrong, and you need to develop some abstraction that makes
the job smaller and moves most of the specifics into some kind of database.

      But what Brooks was talking about was a job of the size of an
operating system kernel, a compiler, or a typical shrink-wrapped
application.  Many such jobs are something a single person could write
with adequate support; examples of each of the above written by individuals
exist.  There are also examples of each of the above written by large
teams, of course.  

      With respect to the FAA application, it's entirely possible that
the whole system will be obsoleted by something that has most of the
smarts in the airplanes, perhaps a successor to ACAS with GPS inputs.
Articles in Aviation Leak indicate that distributed systems are being
worked on, especially for Europe, where cross-border ATC isn't well
integrated.

				John Nagle

Re: chief programmer team organizations was (c++ vs ada results)

[Jim Showalter]

nagle@well.sf.ca.us (John Nagle) writes:

>jls@netcom.COM (Jim Showalter) writes:

>>I'm talking here of things like the multi-MILLION
>>line FAA rewrite of the U.S. air traffic control system.

>      There's a school of thought that if you're writing something that big,
>your approach is wrong, and you need to develop some abstraction that makes
>the job smaller and moves most of the specifics into some kind of database.

There's a school of thought that people who belong to the other school
of thought suffer from having never actually BUILT an air traffic control
system. ;-)

As far as developing abstractions that move the "specifics into some kind
of database", I find "some kind of database" to be rather vague. An air
traffic control system consists of a bewildering array of input sources
(e.g. various kinds of radar) with various signal processing requirements,
critical real time constraints, distributed heterogeneous networking,
and a host of other nasties. In short--they're COMPLICATED. And to top
it off, if they fail, people die. In large numbers. All at once.

It may seem surprising, but the folks that build these things actually
tend to be very bright, very motivated, and very concerned that they
do it correctly. They aren't boobs, and there's a REASON why the code
is big. They're not just writing code to write code. Whenever I hear
someone say that these systems are "too big", I'm reminded of the scene
in "Amadeus" where the emperor chides Mozart for using "too many notes",
to which Mozart replies "Which notes would you have me remove, Sire?".
Which lines of code would you have removed from an air traffic control
system? The display code that manages the screens? The error detection
and correction code? The code that interfaces with the various radars
and normalizes the incoming data? I'm sure there must be literally
hundreds of thousands of superfluous code in there somewhere...
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: chief programmer team organizations was (c++ vs ada results)

[Christopher Warack]

In article <1991Jun25.183805.9549@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>nagle@well.sf.ca.us (John Nagle) writes:
>>jls@netcom.COM (Jim Showalter) writes:
>>>I'm talking here of things like the multi-MILLION
>>>line FAA rewrite of the U.S. air traffic control system.
>
>>      There's a school of thought that if you're writing something that big,
>>your approach is wrong, and you need to develop some abstraction that makes
>>the job smaller and moves most of the specifics into some kind of database.
>
> ...
>
>is big. They're not just writing code to write code. Whenever I hear
>someone say that these systems are "too big", I'm reminded of the scene
>in "Amadeus" where the emperor chides Mozart for using "too many notes",
>to which Mozart replies "Which notes would you have me remove, Sire?".
>Which lines of code would you have removed from an air traffic control
>system? The display code that manages the screens? The error detection
>and correction code? The code that interfaces with the various radars
>and normalizes the incoming data? I'm sure there must be literally
>hundreds of thousands of superfluous code in there somewhere...

I agree with Jim here.  Yet there is even more to consider.  I found
that in building the satellite early warning system more support software
was needed than operational software.  The support software did things
like database maintenance (on top of a DBMS), analysis, system evaluation,
simulation, test support.  I'm sure that FAA has similar needs in these
areas.

Even the operational software can surprise you.  Our biggest chunk of 
code was spent in operator interfaces.  When you have a multi-person
interacting crew whose mistakes can be catastrophic, you're interfaces
need to be simple and powerful enough to do the job fast...  Another
area that adds lots of software throughout a system is dependability.
You can imagine the level of system dependability needed in an early
warning system -- it don't do much good if it isn't running.  I know
that the FAA requirements are orders of magnitude tougher.  To achieve
this level in a large distributed system requires lots of monitoring,
control and diagnostic software that itself must be reliable.

Multi-million lines of code systems don't surprise me at all.  But,
keep in mind that the software doing the primary function is only a 
fraction of the system.

-- Chris

Re: chief programmer team organizations was (c++ vs ada results)

[George C. Harrison, Norfolk State University]

In article <25587@well.sf.ca.us>, nagle@well.sf.ca.us (John Nagle) writes:
>      Real chief programmer teams are very rare.  I've never heard of one
> other than in Brooks' book.  It's very different than having a lead programmer
> or a system architect.  It's organized like a surgical team.  The chief

> [etc.]

> 
>     It's too much of a culture shock for most organization.
> 
> 					John Nagle


Real life success stories are more than welcome to this Software Engineering
Teacher-type.  I've found that Brooks' book seems to place all teams in some
sort of Shangri-La, where managers are infinitely knowlegable and respect their
programmers, customers are always happy, etc.  

Do chief programmer teams really work anywhere outside of a university
classroom or in an experimental industrial setting?  

George C. Harrison, Professor of Computer Science
Norfolk State University, 2401 Corprew Avenue, Norfolk VA 23504
Internet:  g_harrison@vger.nsu.edu    Phone:  804-683-8654

Re: chief programmer team organizations was (c++ vs ada results)

[Harry Erwin]

g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) writes:

>Do chief programmer teams really work anywhere outside of a university
>classroom or in an experimental industrial setting? 

We used a chief programmer team on some tasks on the Site Defense
Program in the mid-1970s at TRW. (This was the same program that
was the basis for many of Barry Boehm's results during the same
period. It seemed to work. 
-- 
Harry Erwin
Internet: erwin@trwacs.fp.trw.com

Re: chief programmer team organizations was (c++ vs ada results)

[Bob Martin]

In article <25587@well.sf.ca.us> nagle@well.sf.ca.us (John Nagle) writes:
>
>     Real chief programmer teams are very rare.  I've never heard of one
>other than in Brooks' book.  It's very different than having a lead programmer
>or a system architect.  It's organized like a surgical team.  The chief
>programmer personally writes most of the delivered code, and everything else
>is set up to facilitate this.  There is an administrator, who reports to the
>chief programmer, to take care of mundane problems.  A toolsmith creates
>tools not part of the deliverable code.  A language lawyer deals with
>compiler and library issues.  A tester tests everything.  A librarian 
>keeps track of everything.  All these people are subordinate to the chief
>programmer.
>
>    It's too much of a culture shock for most organization.
>
>					John Nagle
>    

Not to mention that it is impractical for one programmer to write the bulk
of the code required for today`s applications. 

One of the major problems in developing large projects is making sure that
everyone working on the project has the same 'vision' of what they are
building, and how they are going to build it.  This 'vision' spans concerns
which are as diverse as high-level architecture to coding standards to 
testing methodologies.  Providing this vision ought to be the job of 
the architect or a small group of architects.


-- 
+-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for |
| rmartin@clear.com    |:R::R:C::::M:M:M:M:| my words but me.  I want  |
| uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all   |
+----------------------+:R::R::CCC:M:::::M:| the blame.  So there.     |