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

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

[Operator]

In article <1991Jun26.221811.5950@odi.com>, dlw@odi.com (Dan Weinreb) writes:
|> In article <1991Jun21.222536.18888@netcom.COM> jls@netcom.COM (Jim
Showalter) writes:
|> 
|>    If someone can provide me with an explanation for why junior
programmers
|>    should be making architectural decisions affecting the entire
project,
|>    I'm all ears.
|> 
1: Junior programmers are less experienced, not (necessarily) less
intelligent, less innovative,
less educated, or less resourceful.
1.1: Age has a fairly direct impact on beauty, but on brainpower no
strong correlation has been deomonstrated.

2: Junior programmers are (usually) closer to "fresh out of school" than
we, which means (in general)
2.1: their Profs taught them the solutions to the mistakes that our
Profs made teaching us
2.2: Their education is based on less obsolete hardware, software, and
engineering paradigms than ours
2.3: they are less resistant to learning a new method to solving the
problem at hand than the relativly more
crusted, wizened, and lofty senior.

3: Further embarrassments available upon request, but please keep in
mind that the "half life" of experience in
the computer engineering field is about 5 years. I.e. what you learned 5
years ago is loosing the last parts of its'
relavence now.

Brian (the Senior and student of the Juniors) Brunner

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)H

[house ron]

blakemor@software.software.org (Alex Blakemore) writes:

>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),

>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

The book "Software that Works" by Michael Ward recommends against this for
exactly the reason you mention, among others.  He feels that the programmers
must be involved in design, and that design/programming should alternate,
rather than one coming first in a big chunk followed by the other.
That's my potted version, anyway.

--
Regards,

Ron House.   (s64421@zeus.usq.edu.au)
(By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)

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

[Jim Showalter]

s64421@zeus.usq.EDU.AU (house ron) writes:
>blakemor@software.software.org (Alex Blakemore) writes:
>>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),
>>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

>The book "Software that Works" by Michael Ward recommends against this for
>exactly the reason you mention, among others.  He feels that the programmers
>must be involved in design, and that design/programming should alternate,
>rather than one coming first in a big chunk followed by the other.
>That's my potted version, anyway.

Well, I certainly agree that design/programming should alternate--that's the
basis of iterative development. On the other hand, I
fail to see what this has to do with the notion that some people are better
than others at design, and that those who are the BEST at design probably
ought to be the ones making the most critical decisions on the project.
If someone can provide me with an explanation for why junior programmers
should be making architectural decisions affecting the entire project,
I'm all ears.
-- 
*** 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)H

[Dan Weinreb]

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

   If someone can provide me with an explanation for why junior programmers
   should be making architectural decisions affecting the entire project,
   I'm all ears.

I generally agree with the point you're making.  In my experience,
what really happens is more complex than anything described in any of
these postings.  Iterative development of software within a team is a
social interaction between people.  It's not a question of "command
and obey", but a give-and-take with conversations and discussions.  In
general, when I've been involved with this, the more senior
"architect"-type people end up having more say about design issues.
But if one of the other team members has a good idea, that idea can
certainly be used, and a good architect should pay attention to
everyone's ideas and be quick to credit and use ideas from anyone.
This is part of the process by which the more junior people become
more senior, and it helps keep everybody motivated and excited.  An
important thing about the concensus process is to establish an
atmosphere of mutual respect and trust, so that when there are
disagreements on how to proceed, people will be able to compromise,
or to willingly give up their proposals and go along with someone
else's, without resentment.