Do I Really Need A Supervisor?

Do I Really Need A Supervisor?

[Auntie Alias]

Do I Really Need A Supervisor?

I work for a well known aerospace firm developing embeddded
Ada software for a well known fighter aircraft. I have been
developing embedded Ada software for going on ten years now,
having contributed to missile, aircraft, tank and electronic 
warfare systems now fielded. Like many of you out there I have 
a wide range of experience developing Ada software for a wide 
variety of processors. Like most companies, my present client 
integrates me into a large and deeply nested management 
environment - I have two direct supervisors (one functional, 
one project) who each have their supervisors (functional and 
project) who each have their supervisors, who have their 
supervisors, etc,etc...My question is, Do I really need 
a supervisor?

It has been my observation over the years that one step above
where I work, there is little or no software development done,
i.e, my boss does mostly management "work" - going to meetings,
interfacing with other supervisors, tracking my progress. My
bosses rarely contribute anything of technical value to the
project. Most of the time, they have little or no understanding
of what it is that I am working on. Often times, they have little
or no understanding even how to do my job - sometimes they are
not even trained as software people. Too many times in my career
I have had to explain the most basic ideas of Ada programming
to my boss. (For example, I have twice had to explain to a boss
that an Ada program needs a main procedure - that it was not just
a collection of packages that somehow starts running.) 

In my current assignment, I am on a team of three people, only
two of which are designing or coding. My co-worker has been 
designing our project for the past 2 1/2 years but does not
know Ada. I know Ada, but I do not know the application or her
design as well. Together or singly, either of us could complete
the design, coding, testing and integration of our subsystem into
the airplane. Working together we can get it done even faster. 
But our company feels that we need a supervisor. So they assign
a third person to our team - the supervisor. Our supervisor
is buried with the responsibilities of communicating and 
coordinating with other managers and with the customer (another
division of our corporation). She is unable to contribute 
technically to our work. Added to this supervisor, I have a
functional supervisor and my co-worker also has a separate 
functional supervisor. In addition to these supervisors, my 
project feels a need to have a team of supervisors to formulate
what our software development process should be. These supervisors
it turns out do not even have experience in some cases of 
developing software - let alone Ada software or embedded software.
But there they are, year after year churning out directions for
us to use to develop our software by. And let there be no doubt,
some of these directions and processes are truly assinine.

And over and above these supervisors are still more supervisors.
And they all get together for frequent meetings to study how
much our company is spending developing our software. Charts,
graphs, databases and documents are generated by the thousands
to document how far along I and my co-worker have gotten in
our development efforts. None of the people gathered together
have any idea of how to do the jobs I and my co-worker do, but
there they are, tracking our progress, coordinating our efforts,
collecting metrics, deciding on schedules, estimating efforts,
determining budgets, deciding on policies. And the schedules, 
budgets and estimates are always wrong! (Never even close!) 
Our project suffered a major reorganization at the beginning of 
the year. A new schedule was established. Within two weeks of 
the new schedule being established, it was invalidated by events. 
What possible good are these supervisors?

My supervisors are incapable of doing or understanding my work.
Most of the time, they do not even know what it is that I am 
working on. They are incapable of giving meaningful advice or 
suggestions about the design or implementation of the software. 
They are totally incapable of estimating the time that it will 
take for me to do my work. They are unable to forecast the cost 
of doing my work. They sign my time cards every week, but in 
ten years, I have never once been challenged about my actual 
time spent working. Any communications they have with other 
groups, with other engineers or with the customer could more
sensibly be done by me or my co-worker. They do make a lot of
design policy and scheduling decisions - and most all of them
are poor decisions based on a poor understanding of the 
technology. Either me or my co-worker could have made better
decisions quicker. What possible good are these supervisors?

The task before me and my co-worker involves developing about
15,000 to 20,000 lines of Ada for an embedded controller. It is 
complicated and safety critical, but it is not that big of a
deal. I wrote something very similar last year for another 
client. If I had to, I could write the code at home using an 
ordinary PC and a few thousand dollars worth of equipment. It 
would probably take me a year of full time effort. But the way
our company works, it has so far taken about seven man-years of
effort of the software developers alone. Many more years if you
add in the supervisor overhead - all those people arguing in 
their meetings about how I should do my job. Our effort will
take another two years yet - both me and my co-worker (and the 
supervisor watching over us) - all because we have to develop our
software according to the "process" (#$%@& SEI !!!) designed for 
us by the other supervisors. It buys us nothing; it cost us much. 
What possible good are these supervisors?

I, and engineers like me and my co-worker have clearly demonstrated
that we are trustworthy, competent and capable to get complicated 
military systems implemented and fielded. All this without any real
technical help from our supervisors. (In many cases, in spite of 
our supervisor's "help"!) My question is, Do I really need a 
supervisor? 

My answer is, No. I can do my job better and faster without the 
interference of a supervisor. Just tell us what you want us to
develop a software solution for and leave us alone to develop the
solution. We already know how to do the job. Get out of our way 
and we will do it. Do you want to see our country field the next 
fighter aircraft ahead of schedule and way under budget? Just get 
rid of most of the supervisors - our country will save billions 
and have better weapons as well.

Re: Do I Really Need A Supervisor?

[Mats Weber]

Auntie Alias wrote:

>[...]

> Do you want to see our country field the next
> fighter aircraft ahead of schedule and way under budget? Just get
> rid of most of the supervisors - our country will save billions
> and have better weapons as well.

Try a job out of the military business. You won't be developping
fighters, but there still is very much interesting stuff to do and the
companies tend to be less hierarchized :-)

Re: Do I Really Need A Supervisor?

[David Brown]

bobduff@world.std.com (Robert A Duff) writes:

> I meant exactly what I wrote: An Ada 95 program does not need a main
> procedure (or main function, for that matter).  That is, an Ada 95
> program can consist of a bunch of library packages, without any main
> subprogram.  This is different from Ada 83, which required a main
> subprogram (called a main program in Ada 83, despite the fact that it's
> not a program).
> 
> Note "optionally" and "if specified" in 10.2(7) -- the user is not
> required to have a main subprogram.  Note "if the partition has one" in
> 10.2(21) and "if there is no main subprogram" in 10.2(23).  See also
> 10.2(34), which explains the reason.  See also AARM-10.2(34.e), which
> says that this change is a language extension.

I guess then a GNAT question is in order.  How would you go about
producing a partition with GNAT that doesn't have a main subprogram.
If I just give gnatbind packages without a main subprogram, it
complains that there is no main subprogram.  If I specify -n to
indicate that there is no main subprogram, then it doesn't generate a
function called main.  I could use it this way, but I would have to
write my own main that just called adainit.

I guess I'm wondering how 10.2(23) get's addressed.  I suppose that
requiring the user to write a C routine to call adainit could be
called "implementation defined" :-).

Dave Brown

Re: Do I Really Need A Supervisor?

[Robert Dewar]

Sam said

<<What do you mean? He didn't write "a 'main' procedure", but "a main
procedure" which is quite different.>>

Bob meant what he said, in Ada 83, a main subprogram (not necessarily
called main, of course) is required, but this requirement is eliminated
in Ada 95. 

Seems a silly change to me, but it is a harmless enough one.

GNAT supports this, but only with some fiddling (you need a dummy C main
program with a call to adafinal and adainit, and then you bind with
-gnatn, saying there is no main program).

The idea is that you can do all your processing in elaboration code, a 
perfectly horrible way of structuring a program (which is why I think
this is a silly change), but one that makes perfectly good technical 
sense.

Note: I find that many Ada programmers get carried away with elaboration
code. They think "hey! isn't this neat, I can do everything at elaboration
time", and as usual when people get the "hey! isn't this neat" thought, they
are in fact creating obscure junk :-)

There is even one Ada compiler with a null main program where each pass is
a package that does its work in package elaboration code, and pragma
Elaborate is used to make sure that the passes are executed (i.e. elaborated
at package elaboration time) in the right order -- hey! isn't that neat? :-)

Re: Do I Really Need A Supervisor?

[Randall Edick]

Jay Martin wrote:
> 
> Auntie Alias <antialias@earthlink.net> writes:
> 
> >Do I Really Need A Supervisor?
> 
> >I work for a well known aerospace firm developing embeddded
> >Ada software for a well known fighter aircraft. I have been
> >developing embedded Ada software for going on ten years now,
> >having contributed to missile, aircraft, tank and electronic
> >warfare systems now fielded. Like many of you out there I have
> >a wide range of experience developing Ada software for a wide
> >variety of processors. Like most companies, my present client
> >integrates me into a large and deeply nested management
> >environment - I have two direct supervisors (one functional,
> >one project) who each have their supervisors (functional and
> >project) who each have their supervisors, who have their
> >supervisors, etc,etc...My question is, Do I really need
> >a supervisor?
> 
> >It has been my observation over the years that one step above
> >where I work, there is little or no software development done,
> >i.e, my boss does mostly management "work" - going to meetings,
> >interfacing with other supervisors, tracking my progress. My
> >bosses rarely contribute anything of technical value to the
> >project. Most of the time, they have little or no understanding
> >of what it is that I am working on. Often times, they have little
> >or no understanding even how to do my job - sometimes they are
> >not even trained as software people. Too many times in my career
> >I have had to explain the most basic ideas of Ada programming
> >to my boss. (For example, I have twice had to explain to a boss
> >that an Ada program needs a main procedure - that it was not just
> >a collection of packages that somehow starts running.)
> 
....

SAY IT BROTHER.  

Please see the other items I posted today. I'm fed up with this
nonsense, and I'm telling my supervision.

Where would we be without managment?  An excellent example is
Linux.  NO MANAGEMENT.  One of the largest, most complex, best
technical, best selling efforts of all time.  All done by techies
over the internet.

Speaking up is good for our companies.

Try what I'm doing.  I write software on my own time with plans
to sell for myself (I got formal permission).  It is an 
understatement to say that I outproduce my group in my spare
time.  I'm not the best technically either, I'm simple able 
to ditch this crap.

-- 

===============================================================
Randall Edick                                tel   (206)234-7882
Structures Research				    		 fax   (206)234-1499
Boeing Company                    
rre9518@es5031.ca.boeing.com                
================================================================

Re: Do I Really Need A Supervisor?

[Robert Dewar]

Dave Brown says

<<I guess then a GNAT question is in order.  How would you go about
producing a partition with GNAT that doesn't have a main subprogram.
If I just give gnatbind packages without a main subprogram, it
complains that there is no main subprogram.  If I specify -n to
indicate that there is no main subprogram, then it doesn't generate a
function called main.  I could use it this way, but I would have to
write my own main that just called adainit.

I guess I'm wondering how 10.2(23) get's addressed.  I suppose that
requiring the user to write a C routine to call adainit could be
called "implementation defined" :-).>>

That's right, although you need to remember to call adafinal as well,
so you need a main program that says

main ()
{adainit(); adafinal():}

And that is now 10.2(23) gets addressed if anyone needs this marginal
feature!

Re: Do I Really Need A Supervisor?

[Robert A Duff]

In article <3327438E.942@earthlink.net>,
Auntie Alias  <antialias@earthlink.net> wrote:
>... Too many times in my career
>I have had to explain the most basic ideas of Ada programming
>to my boss. (For example, I have twice had to explain to a boss
>that an Ada program needs a main procedure - that it was not just
>a collection of packages that somehow starts running.) 

An Ada 95 program does not need a main procedure.

- Bob

Re: Do I Really Need A Supervisor?

[Jay Martin]

Auntie Alias <antialias@earthlink.net> writes:

>Do I Really Need A Supervisor?

>I work for a well known aerospace firm developing embeddded
>Ada software for a well known fighter aircraft. I have been
>developing embedded Ada software for going on ten years now,
>having contributed to missile, aircraft, tank and electronic 
>warfare systems now fielded. Like many of you out there I have 
>a wide range of experience developing Ada software for a wide 
>variety of processors. Like most companies, my present client 
>integrates me into a large and deeply nested management 
>environment - I have two direct supervisors (one functional, 
>one project) who each have their supervisors (functional and 
>project) who each have their supervisors, who have their 
>supervisors, etc,etc...My question is, Do I really need 
>a supervisor?

>It has been my observation over the years that one step above
>where I work, there is little or no software development done,
>i.e, my boss does mostly management "work" - going to meetings,
>interfacing with other supervisors, tracking my progress. My
>bosses rarely contribute anything of technical value to the
>project. Most of the time, they have little or no understanding
>of what it is that I am working on. Often times, they have little
>or no understanding even how to do my job - sometimes they are
>not even trained as software people. Too many times in my career
>I have had to explain the most basic ideas of Ada programming
>to my boss. (For example, I have twice had to explain to a boss
>that an Ada program needs a main procedure - that it was not just
>a collection of packages that somehow starts running.) 

>In my current assignment, I am on a team of three people, only
>two of which are designing or coding. My co-worker has been 
>designing our project for the past 2 1/2 years but does not
>know Ada. I know Ada, but I do not know the application or her
>design as well. Together or singly, either of us could complete
>the design, coding, testing and integration of our subsystem into
>the airplane. Working together we can get it done even faster. 
>But our company feels that we need a supervisor. So they assign
>a third person to our team - the supervisor. Our supervisor
>is buried with the responsibilities of communicating and 
>coordinating with other managers and with the customer (another
>division of our corporation). She is unable to contribute 
>technically to our work. Added to this supervisor, I have a
>functional supervisor and my co-worker also has a separate 
>functional supervisor. In addition to these supervisors, my 
>project feels a need to have a team of supervisors to formulate
>what our software development process should be. These supervisors
>it turns out do not even have experience in some cases of 
>developing software - let alone Ada software or embedded software.
>But there they are, year after year churning out directions for
>us to use to develop our software by. And let there be no doubt,
>some of these directions and processes are truly assinine.

>And over and above these supervisors are still more supervisors.
>And they all get together for frequent meetings to study how
>much our company is spending developing our software. Charts,
>graphs, databases and documents are generated by the thousands
>to document how far along I and my co-worker have gotten in
>our development efforts. None of the people gathered together
>have any idea of how to do the jobs I and my co-worker do, but
>there they are, tracking our progress, coordinating our efforts,
>collecting metrics, deciding on schedules, estimating efforts,
>determining budgets, deciding on policies. And the schedules, 
>budgets and estimates are always wrong! (Never even close!) 
>Our project suffered a major reorganization at the beginning of 
>the year. A new schedule was established. Within two weeks of 
>the new schedule being established, it was invalidated by events. 
>What possible good are these supervisors?

>My supervisors are incapable of doing or understanding my work.
>Most of the time, they do not even know what it is that I am 
>working on. They are incapable of giving meaningful advice or 
>suggestions about the design or implementation of the software. 
>They are totally incapable of estimating the time that it will 
>take for me to do my work. They are unable to forecast the cost 
>of doing my work. They sign my time cards every week, but in 
>ten years, I have never once been challenged about my actual 
>time spent working. Any communications they have with other 
>groups, with other engineers or with the customer could more
>sensibly be done by me or my co-worker. They do make a lot of
>design policy and scheduling decisions - and most all of them
>are poor decisions based on a poor understanding of the 
>technology. Either me or my co-worker could have made better
>decisions quicker. What possible good are these supervisors?

>The task before me and my co-worker involves developing about
>15,000 to 20,000 lines of Ada for an embedded controller. It is 
>complicated and safety critical, but it is not that big of a
>deal. I wrote something very similar last year for another 
>client. If I had to, I could write the code at home using an 
>ordinary PC and a few thousand dollars worth of equipment. It 
>would probably take me a year of full time effort. But the way
>our company works, it has so far taken about seven man-years of
>effort of the software developers alone. Many more years if you
>add in the supervisor overhead - all those people arguing in 
>their meetings about how I should do my job. Our effort will
>take another two years yet - both me and my co-worker (and the 
>supervisor watching over us) - all because we have to develop our
>software according to the "process" (#$%@& SEI !!!) designed for 
>us by the other supervisors. It buys us nothing; it cost us much. 
>What possible good are these supervisors?

>I, and engineers like me and my co-worker have clearly demonstrated
>that we are trustworthy, competent and capable to get complicated 
>military systems implemented and fielded. All this without any real
>technical help from our supervisors. (In many cases, in spite of 
>our supervisor's "help"!) My question is, Do I really need a 
>supervisor? 

>My answer is, No. I can do my job better and faster without the 
>interference of a supervisor. Just tell us what you want us to
>develop a software solution for and leave us alone to develop the
>solution. We already know how to do the job. Get out of our way 
>and we will do it. Do you want to see our country field the next 
>fighter aircraft ahead of schedule and way under budget? Just get 
>rid of most of the supervisors - our country will save billions 
>and have better weapons as well.

Heh. Silly person, the purpose of Defense software is not efficiency,
but inefficiency.  The goal is to suck as much $$$ out of the DOD
while producing little to zilch.  Your company sounds like it is
doing brilliant job at that. Recognise their genius!

(this must go to comp.software-eng)

Jay

Re: Do I Really Need A Supervisor?

[Jay Martin]

Auntie Alias <antialias@earthlink.net> writes:

>Do I Really Need A Supervisor?

>I work for a well known aerospace firm developing embeddded
>Ada software for a well known fighter aircraft. I have been
>developing embedded Ada software for going on ten years now,
>having contributed to missile, aircraft, tank and electronic 
>warfare systems now fielded. Like many of you out there I have 
>a wide range of experience developing Ada software for a wide 
>variety of processors. Like most companies, my present client 
>integrates me into a large and deeply nested management 
>environment - I have two direct supervisors (one functional, 
>one project) who each have their supervisors (functional and 
>project) who each have their supervisors, who have their 
>supervisors, etc,etc...My question is, Do I really need 
>a supervisor?

>It has been my observation over the years that one step above
>where I work, there is little or no software development done,
>i.e, my boss does mostly management "work" - going to meetings,
>interfacing with other supervisors, tracking my progress. My
>bosses rarely contribute anything of technical value to the
>project. Most of the time, they have little or no understanding
>of what it is that I am working on. Often times, they have little
>or no understanding even how to do my job - sometimes they are
>not even trained as software people. Too many times in my career
>I have had to explain the most basic ideas of Ada programming
>to my boss. (For example, I have twice had to explain to a boss
>that an Ada program needs a main procedure - that it was not just
>a collection of packages that somehow starts running.) 

>In my current assignment, I am on a team of three people, only
>two of which are designing or coding. My co-worker has been 
>designing our project for the past 2 1/2 years but does not
>know Ada. I know Ada, but I do not know the application or her
>design as well. Together or singly, either of us could complete
>the design, coding, testing and integration of our subsystem into
>the airplane. Working together we can get it done even faster. 
>But our company feels that we need a supervisor. So they assign
>a third person to our team - the supervisor. Our supervisor
>is buried with the responsibilities of communicating and 
>coordinating with other managers and with the customer (another
>division of our corporation). She is unable to contribute 
>technically to our work. Added to this supervisor, I have a
>functional supervisor and my co-worker also has a separate 
>functional supervisor. In addition to these supervisors, my 
>project feels a need to have a team of supervisors to formulate
>what our software development process should be. These supervisors
>it turns out do not even have experience in some cases of 
>developing software - let alone Ada software or embedded software.
>But there they are, year after year churning out directions for
>us to use to develop our software by. And let there be no doubt,
>some of these directions and processes are truly assinine.

>And over and above these supervisors are still more supervisors.
>And they all get together for frequent meetings to study how
>much our company is spending developing our software. Charts,
>graphs, databases and documents are generated by the thousands
>to document how far along I and my co-worker have gotten in
>our development efforts. None of the people gathered together
>have any idea of how to do the jobs I and my co-worker do, but
>there they are, tracking our progress, coordinating our efforts,
>collecting metrics, deciding on schedules, estimating efforts,
>determining budgets, deciding on policies. And the schedules, 
>budgets and estimates are always wrong! (Never even close!) 
>Our project suffered a major reorganization at the beginning of 
>the year. A new schedule was established. Within two weeks of 
>the new schedule being established, it was invalidated by events. 
>What possible good are these supervisors?

>My supervisors are incapable of doing or understanding my work.
>Most of the time, they do not even know what it is that I am 
>working on. They are incapable of giving meaningful advice or 
>suggestions about the design or implementation of the software. 
>They are totally incapable of estimating the time that it will 
>take for me to do my work. They are unable to forecast the cost 
>of doing my work. They sign my time cards every week, but in 
>ten years, I have never once been challenged about my actual 
>time spent working. Any communications they have with other 
>groups, with other engineers or with the customer could more
>sensibly be done by me or my co-worker. They do make a lot of
>design policy and scheduling decisions - and most all of them
>are poor decisions based on a poor understanding of the 
>technology. Either me or my co-worker could have made better
>decisions quicker. What possible good are these supervisors?

>The task before me and my co-worker involves developing about
>15,000 to 20,000 lines of Ada for an embedded controller. It is 
>complicated and safety critical, but it is not that big of a
>deal. I wrote something very similar last year for another 
>client. If I had to, I could write the code at home using an 
>ordinary PC and a few thousand dollars worth of equipment. It 
>would probably take me a year of full time effort. But the way
>our company works, it has so far taken about seven man-years of
>effort of the software developers alone. Many more years if you
>add in the supervisor overhead - all those people arguing in 
>their meetings about how I should do my job. Our effort will
>take another two years yet - both me and my co-worker (and the 
>supervisor watching over us) - all because we have to develop our
>software according to the "process" (#$%@& SEI !!!) designed for 
>us by the other supervisors. It buys us nothing; it cost us much. 
>What possible good are these supervisors?

>I, and engineers like me and my co-worker have clearly demonstrated
>that we are trustworthy, competent and capable to get complicated 
>military systems implemented and fielded. All this without any real
>technical help from our supervisors. (In many cases, in spite of 
>our supervisor's "help"!) My question is, Do I really need a 
>supervisor? 

>My answer is, No. I can do my job better and faster without the 
>interference of a supervisor. Just tell us what you want us to
>develop a software solution for and leave us alone to develop the
>solution. We already know how to do the job. Get out of our way 
>and we will do it. Do you want to see our country field the next 
>fighter aircraft ahead of schedule and way under budget? Just get 
>rid of most of the supervisors - our country will save billions 
>and have better weapons as well.

Heh. As anyone in defense software knows, the main goal of defense
software is to suck the maximum $$$ out of the DOD while producing
little to zilch.  So given inefficiency as something to optimize, your
company sounds like it is doing a brilliant job.  Recognize their
genius!  (forwarded to comp.software-eng)

Jay

Re: Do I Really Need A Supervisor?

[Samuel Tardieu]

>>>>> "Bob" == Robert A Duff <bobduff@world.std.com> writes:

Bob> In article <3327438E.942@earthlink.net>, Auntie Alias
Bob> <antialias@earthlink.net> wrote:

>> ... Too many times in my career I have had to explain the most
>> basic ideas of Ada programming to my boss. (For example, I have
>> twice had to explain to a boss that an Ada program needs a main
>> procedure - that it was not just a collection of packages that
>> somehow starts running.)

Bob> An Ada 95 program does not need a main procedure.

What do you mean? He didn't write "a 'main' procedure", but "a main
procedure" which is quite different.

  Sam
--
Samuel Tardieu -- sam@ada.eu.org

Re: Do I Really Need A Supervisor?

[Robert A Duff]

In article <qw6sp203wko.fsf@esmeralda.enst.fr>,
Samuel Tardieu  <sam@ada.eu.org> wrote:
>Bob> An Ada 95 program does not need a main procedure.
>
>What do you mean? He didn't write "a 'main' procedure", but "a main
>procedure" which is quite different.

I meant exactly what I wrote: An Ada 95 program does not need a main
procedure (or main function, for that matter).  That is, an Ada 95
program can consist of a bunch of library packages, without any main
subprogram.  This is different from Ada 83, which required a main
subprogram (called a main program in Ada 83, despite the fact that it's
not a program).

Note "optionally" and "if specified" in 10.2(7) -- the user is not
required to have a main subprogram.  Note "if the partition has one" in
10.2(21) and "if there is no main subprogram" in 10.2(23).  See also
10.2(34), which explains the reason.  See also AARM-10.2(34.e), which
says that this change is a language extension.

- Bob

Re: Do I Really Need A Supervisor?

[Michael F Brenner]

You are wrong for posting this to comp.lang.ada, but right in observing
that supervisors of technical people are pure overhead, and we have
about 92 percent too many of them, similar to the fact that we have
far too many laws, fears, ignorances, intolerances, and cravings. By
using process reengineering metrics to measure the cost and contribution of 
the supervisors you would be able to cost-justify elminating all but one
level of management supervision, all but one level of technical supervision,
and all interpersonal rivalries, scapegoating, and personality conflicts.
However, this justification will not result in the supervisors going away,
because modern business exists to support those supervisors, not the
engineers or customers. If you start your own business, you have the right
to choose to support the engineers and customers instead of the supervisors.
But look at what programmers are doing today, almost all user interfaces
and administrative overhead work like legal justifications, medical
justification databases, and psycho-socio workers carrying out their program
of identifying witches to hunt. This will continue until society as a whole 
decides that it is more fun to build cities underwaters, on Moon, and on Mars, 
to replace atom smashing with fusion energy, and to share our world with
artificial computer intelligences to enhance our enjoyment of life, our
love of our fellows, service to our planet, both physical and spiritual.
 

Re: Do I Really Need A Supervisor?

[David Wheeler]

Auntie Alias (antialias@earthlink.net) wrote:
: Do I Really Need A Supervisor?

I recommend a large helping of Scott Adam's "Dilbert".
Sounds like you're working in his world :-(.


--- David A. Wheeler
    dwheeler@ida.org

Re: Do I Really Need A Supervisor?

[Adam Beneschan]

In article <3327438E.942@earthlink.net> antialias@earthlink.net writes:

> Do I Really Need A Supervisor?

Yes.

                                -- Adam

Re: Do I Really Need A Supervisor?

[Laurent Guerby]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> The idea is that you can do all your processing in elaboration code, a 
> perfectly horrible way of structuring a program (which is why I think
> this is a silly change), but one that makes perfectly good technical 
> sense.

   An Ada program without main subprogram does not necessary rely on
elaboration, think about a program with library level tasks.

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Do I Really Need A Supervisor?

[Robert A Duff]

In article <dewar.858314379@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>That's right, although you need to remember to call adafinal as well,
>so you need a main program that says
>
>main ()
>{adainit(); adafinal():}
>
>And that is now 10.2(23) gets addressed if anyone needs this marginal
>feature!

Nah, nobody's going to do that.  I'd rather write "procedure main is
begin null; end;".

I'm not sure which feature you're calling "marginal" -- the lack of a
main procedure is essential (required) for shared-passive partitions.
Perhaps you mean "lack of a main, for an active partition" is marginal
-- which I would agree with.

- Bob

Re: Do I Really Need A Supervisor?

[John Apa]

Jay Martin wrote:
> 
> Auntie Alias <antialias@earthlink.net> writes:
> 
> >Do I Really Need A Supervisor?
> 
> >I work for a well known aerospace firm developing embeddded
> >Ada software for a well known fighter aircraft. I have been
> >developing embedded Ada software for going on ten years now,
> >having contributed to missile, aircraft, tank and electronic
> >warfare systems now fielded. Like many of you out there I have
> >a wide range of experience developing Ada software for a wide
> >variety of processors. Like most companies, my present client
> >integrates me into a large and deeply nested management
> >environment - I have two direct supervisors (one functional,
> >one project) who each have their supervisors (functional and
> >project) who each have their supervisors, who have their
> >supervisors, etc,etc...My question is, Do I really need
> >a supervisor?

I just left a company that had 50+% management. It was a good place and
had lot's of good people, but making progress tended to be very
political. And hence very stressful. If any of my friends are reading
this, don't worry I won't name names!

> 
> >It has been my observation over the years that one step above
> >where I work, there is little or no software development done,
> >i.e, my boss does mostly management "work" - going to meetings,
> >interfacing with other supervisors, tracking my progress. My
> >bosses rarely contribute anything of technical value to the
> >project. Most of the time, they have little or no understanding
> >of what it is that I am working on. Often times, they have little
> >or no understanding even how to do my job - sometimes they are
> >not even trained as software people. Too many times in my career
> >I have had to explain the most basic ideas of Ada programming
> >to my boss. (For example, I have twice had to explain to a boss
> >that an Ada program needs a main procedure - that it was not just
> >a collection of packages that somehow starts running.)

True, the pointy haired guys seem to be all over. And there's no way
(legally) to get rid of them. The only method is to give their phone #
to a headhunter, or to leave yourself.

> 
> >In my current assignment, I am on a team of three people, only
> >two of which are designing or coding. My co-worker has been
> >designing our project for the past 2 1/2 years but does not
> >know Ada. I know Ada, but I do not know the application or her
> >design as well. Together or singly, either of us could complete
> >the design, coding, testing and integration of our subsystem into
> >the airplane. Working together we can get it done even faster.
> >But our company feels that we need a supervisor. So they assign
> >a third person to our team - the supervisor. Our supervisor
> >is buried with the responsibilities of communicating and
> >coordinating with other managers and with the customer (another
> >division of our corporation). She is unable to contribute
> >technically to our work. Added to this supervisor, I have a
> >functional supervisor and my co-worker also has a separate
> >functional supervisor. In addition to these supervisors, my
> >project feels a need to have a team of supervisors to formulate
> >what our software development process should be. These supervisors
> >it turns out do not even have experience in some cases of
> >developing software - let alone Ada software or embedded software.
> >But there they are, year after year churning out directions for
> >us to use to develop our software by. And let there be no doubt,
> >some of these directions and processes are truly assinine.

This is not a new thing. My father has been working in the defense/space
industry for over 40 years. He's a system engineer, and knows more about
software and design than many of the SW managers below him. But they
went to school and _know_ (a few CS-MS) how to do it. He's content to
give them his advice, and let them do as they want. When they fail and
decide that he was right, they are amazed that someone who remembers
WWII understands software. Really, it's not about SW it's about
engineering. Managers should manage and stay our of the technical forum.
Their job is to support you in getting your job done so that it mets
spec.

> 
> >And over and above these supervisors are still more supervisors.
> >And they all get together for frequent meetings to study how
> >much our company is spending developing our software. Charts,
> >graphs, databases and documents are generated by the thousands
> >to document how far along I and my co-worker have gotten in
> >our development efforts. None of the people gathered together
> >have any idea of how to do the jobs I and my co-worker do, but
> >there they are, tracking our progress, coordinating our efforts,
> >collecting metrics, deciding on schedules, estimating efforts,
> >determining budgets, deciding on policies. And the schedules,
> >budgets and estimates are always wrong! (Never even close!)
> >Our project suffered a major reorganization at the beginning of
> >the year. A new schedule was established. Within two weeks of
> >the new schedule being established, it was invalidated by events.
> >What possible good are these supervisors?

Landfill? Seriously, good supervisors exist. I've been lucky to have a
few. They should insulate you from the politics of the company and the
customer. When they fail to do this, you have big problems. One manager
I had was so confrontational that everyone just stopped designing and
did exactly what he said. Now the average team member had 10 years
experience with the project, and 6 years ada. The _manager_ had never
been on a sucessful ada project, and did not have any domain experience.
Result, half the team is now working elsewhere. And major
schedule/budget slips. To be blunt, a blood-fest.

My current leader loves schedules, they make him laugh a lot. Everytime
he hands one out he qualifies it by saying, "If you don't like this one,
wait till tomorrow." The problem with schedule is that noon knows how to
do them. I've had people ask me how long its going to take to do
something, I say 6 weeks. By the time I get the schedule back it says
I've got two weeks, and they started a month ago. That's just stupid.
And if you allow that to happen then, you are also at fault. You need to
go to the PMO and tell them that your estimates are not being reflected
in the schedule, and that you will not accept any non-written direction
from that point on. Otherwise, you know where you'll get it. Yes, it's
not fun to have to play the game, but you need to protect yourself.
Think of it as a pump, and you know what flows downhill.

If you can't go to the PMO because you don't trust them, then why are
you working there? You need to be a team, if PMO doesn't want to hear
bad news or get ideas for making things better then perhaps they aren't
going to be very successful.

> 
> >My supervisors are incapable of doing or understanding my work.
> >Most of the time, they do not even know what it is that I am
> >working on. They are incapable of giving meaningful advice or
> >suggestions about the design or implementation of the software.
> >They are totally incapable of estimating the time that it will
> >take for me to do my work. They are unable to forecast the cost
> >of doing my work. They sign my time cards every week, but in
> >ten years, I have never once been challenged about my actual
> >time spent working. Any communications they have with other
> >groups, with other engineers or with the customer could more
> >sensibly be done by me or my co-worker. They do make a lot of
> >design policy and scheduling decisions - and most all of them
> >are poor decisions based on a poor understanding of the
> >technology. Either me or my co-worker could have made better
> >decisions quicker. What possible good are these supervisors?

Having told a sad story about a bad situation, I should share a good
story. I had a manager many years ago, who didn't care how you
implemented something as long as it met the specs (specs we all designed
and agreed on). He was a great guy to work for. He backed us up when
management was looking for scape goats, and fought to reward those of us
who did good work. It was wonderful. We all had the freedom to use our
knowledge and do work. We could also take risks and try new things
because we knew he wouldn't pull the rug out from under us. Most of all,
everyone was happy and productive.

Maybe another happy story too. Just before I left my last job we got a
new manager to replace our confrontational one. The new manager was
great. She actually talked to us and wanted to help everyone set goals
that they wanted to accomplish. She really cared about the team and
wanted it to be sucessful. She knew what she was doing and had great
ideas of things to do in the future. I'd have stayed but I was ready for
a change and wanted to try a different location. I wanted to get out of
LA and someplace where people actually said hello and smiled.

> 
> >The task before me and my co-worker involves developing about
> >15,000 to 20,000 lines of Ada for an embedded controller. It is
> >complicated and safety critical, but it is not that big of a
> >deal. I wrote something very similar last year for another
> >client. If I had to, I could write the code at home using an
> >ordinary PC and a few thousand dollars worth of equipment. It
> >would probably take me a year of full time effort. But the way
> >our company works, it has so far taken about seven man-years of
> >effort of the software developers alone. Many more years if you
> >add in the supervisor overhead - all those people arguing in
> >their meetings about how I should do my job. Our effort will
> >take another two years yet - both me and my co-worker (and the
> >supervisor watching over us) - all because we have to develop our
> >software according to the "process" (#$%@& SEI !!!) designed for
> >us by the other supervisors. It buys us nothing; it cost us much.
> >What possible good are these supervisors?

It is true that SEI or any process initially adds to cost. It is
frustrating, especially when it seems like you sit in meetings all day
and argue, sorry, _discuss_ how many angels can sit on a pin(like angels
would actually sit on a pin, ouch!) I've been there, the record is 33
hours in three days discussing such trivial crap that it almost makes me
sick. But I've also seen how a _good_ process can be helpful, and over
the long term can save money. The most productive I've ever been was on
a small project with two other SW-eng, we averaged over 10 lines per day
each of finished running code. While we didn't have a process
documented, we were (and still are) good friends so we knew how to work
together and the process evolved from that.

If the process adds so much to your bids that you lose contracts or fail
to meet them, there is something wrong. There is nothing wrong with
failing, unless it's failing to learn from your mistakes. A bad process
will shut down a company faster than acts of God. A process has to be a
living thing, that adapts with your market, skills, and goals. If it
doesn't change then you will not evolve with technology, and will be
left behind. If you know of a problem with the process, get a copy,
redline it and start the revision process. If you cannot do this then
there is a _serious_ problem. Now, your change may not be deemed
appropriate, but at least there will be discussion among your peer group
that should provide you with some satisfaction. Maybe it's a great idea,
but we have to deliever tomorrow. Sometimes there are great reasons to
do something one way, you just aren't aware of some of the subtle
reasons. The change process should either result in change or provide a
solid reason for why no change ws needed.

> 
> >I, and engineers like me and my co-worker have clearly demonstrated
> >that we are trustworthy, competent and capable to get complicated
> >military systems implemented and fielded. All this without any real
> >technical help from our supervisors. (In many cases, in spite of
> >our supervisor's "help"!) My question is, Do I really need a
> >supervisor?

I love working individually or in small teams. Much more efficient that
the larger teams I've been in. It's wonderful. The problem is that most
systems now days are getting to complicated for small teams of 1-5
people. Keeping teams small is great, but on a large project you need
more than a few small teams. That means someone to coordinate everyones
actions. Good managers should look out for the well being of the team
and help it to work. Teams will have natural leaders within them, let
that happen. Generally I've found that some of the best engineers
(HW/SW) tend to be very independent. Free thought should be encouraged.
Though not at the expense of team members.

No one needs to have someone standing over them asking "how much
longer", "does it works yet", "lack of adherance to the process will be
reflected in your review", "what does this thing do?", "team member X
left because he wasn't good enough, hope you learn from that", "I alone
know what is right for the project, you engineers don't know sh%*".

> 
> >My answer is, No. I can do my job better and faster without the
> >interference of a supervisor. Just tell us what you want us to
> >develop a software solution for and leave us alone to develop the
> >solution. We already know how to do the job. Get out of our way
> >and we will do it. Do you want to see our country field the next
> >fighter aircraft ahead of schedule and way under budget? Just get
> >rid of most of the supervisors - our country will save billions
> >and have better weapons as well.
> 
> Heh. As anyone in defense software knows, the main goal of defense
> software is to suck the maximum $$$ out of the DOD while producing
> little to zilch.  So given inefficiency as something to optimize, your
> company sounds like it is doing a brilliant job.  Recognize their
> genius!  (forwarded to comp.software-eng)
> 
> Jay

Gee, Jay, perhaps you don't know how many brave men have died (to much
revisionist history in CA schools) so that you can go to a bleeding
heart school and protest defending this country. It's a good thing
defense funding created the internet, and developed computers so many
years ago. Otherwise you wouldn't be able to broadcast your short
sighted, ignorant views to the entire world, and potential employers.

Most people are not in defense for the money, the technology is generaly
leading edge, and the tasks are very challenging. Some one has to
provide our troops with good equipment so that in future conflicts (and
there will be more, peace is dangerous) not so many will have to die
defending your sorry life.

You'll probably work for M$ and learn how to suck the life out of an
entire industry, not to mention fleecing the people, stealing ideas, and
setting up monopolies. Now that is much better than helping to defend
our country. It must be. I hear it pays good to.

Oops, didn't realize you're a cs at ucla. I'll type slower so you can
understand.

My apologies in advance for the CS/ucla crack to all the CS/ucla people
who _know_ what they are doing. I've met to many from there who can't
find the power switch. To busy protesting something perhaps? Maybe 400
students to a class is to much, especially with no professors. I used to
live there and I know what goes on.
-- 
***********************************
That's my opinion, not Honeywell's.
John Thomas Apa
Honeywell Defense Avionics Systems
Albuquerque, New Mexico.
***********************************

Re: Do I Really Need A Supervisor?

[Jon S Anthony]

In article <332831DE.6055@elca-matrix.ch> Mats Weber <Mats.Weber@elca-matrix.ch> writes:

> Auntie Alias wrote:
> 
> >[...]
> 
> > Do you want to see our country field the next
> > fighter aircraft ahead of schedule and way under budget? Just get
> > rid of most of the supervisors - our country will save billions
> > and have better weapons as well.
> 
> Try a job out of the military business. You won't be developping
> fighters, but there still is very much interesting stuff to do and the
> companies tend to be less hierarchized :-)

Don't be so sure.  This scenario of Auntie Alias applies to every
"big" *commercial* company I have had direct or indirect (i.e., the
same sort of lament friends have poured out over a beer about their
company) experience of.  This is simply BAU in the last decade of the
20th century...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Do I Really Need A Supervisor?

[David Taylor]

In article <33285CC6.1CFB@ss5010.ca.boeing.com>, Randall Edick
<rre9518@ss5010.ca.boeing.com> wrote:

>Jay Martin wrote:
>> 
>> Auntie Alias <antialias@earthlink.net> writes:
>> 
>> >Do I Really Need A Supervisor?
>> 
>> >I work for a well known aerospace firm developing embeddded
[[snip]]
>SAY IT BROTHER.  
>
>Please see the other items I posted today. I'm fed up with this
>nonsense, and I'm telling my supervision.
>
>Where would we be without managment?  An excellent example is
>Linux.  NO MANAGEMENT.  One of the largest, most complex, best
>technical, best selling efforts of all time.  All done by techies
>over the internet.

Another example is the Internet itself. There is no one "in charge". There
is some real crap on the Internet, but there is a lot of real genius.

dave

Re: Do I Really Need A Supervisor?

[Robert Dewar]

Laurent says

<<   An Ada program without main subprogram does not necessary rely on
elaboration, think about a program with library level tasks.>>

Yes, yes, I know, that is in fact the argument used for putting in the
feature. I still think it is a gratuitous change. One problem is that
the organization of a program written this way is much less clear for
a reader, so I think this is a change that favors the writer over the
reader.

What's the big deal in having a main program that says

   with Library_Tasks;
   procedure Main is
   --  Note: all work is done in the tasks started in Library_Tasks
   begin
      null;
   end;

The main program is an excellent place to act as a focus for critical
system level "guidepost" docuementation, and I think that it is better
style to supply a dummy main program, even in the very unlikely case
where this makes good sense as a system structure.

Re: Do I Really Need A Supervisor?

[Robert Dewar]

Bob Duff said

<<I'm not sure which feature you're calling "marginal" -- the lack of a
main procedure is essential (required) for shared-passive partitions.
Perhaps you mean "lack of a main, for an active partition" is marginal
-- which I would agree with.>>

Yup, absolutely, I was talking about active partitions!

Re: Do I Really Need A Supervisor?

[Richard Kenner]

In article <33285CC6.1CFB@ss5010.ca.boeing.com>, Randall Edick
>Where would we be without managment?  An excellent example is
>Linux.  NO MANAGEMENT.  One of the largest, most complex, best
>technical, best selling efforts of all time.  All done by techies
>over the internet.

Actually, Linux is a good example of why management is very useful.
The initial work was done by one person workign alone, so management
wasn't very meaningful.

But now, it seems everybody is developing packages for it and there's
all sort of incompatibily problem between (e.g.) versions of
libc, binutils, and GCC, to say nothing of multiple different object
file formats in use.

These problems are due to lack of a central management.

GCC is another example of a successful and large program developed
by "techies over the Internet", but there *is* one person in
overall charge of that effort (originally RMS and now me) who makes
sure that it's all coordinated.

Re: Do I Really Need A Supervisor?

[Robert Dewar]

i<< I didn't mean to imply that all management is bad.  Certainly not.
 The problem is that there are a LOT of people who want to be managers
and they all need a technical type i.e. donkey to justify it.  Once this
stuff starts it is VERY HARD TO STOP IT.  Linux/GNU is a juicy excuse
for bureacracy. When it happens it could kill it.   The saving grace
may be there not a lot of money in it.

I don't think you want a central management group.  You want a
central TECHNICAL group.>>

I know many programmers feel this way, but I certainly would not hire them.
Pretty strong central management is essential to software quality in my
view.

Re: Do I Really Need A Supervisor?

[Graham C. Hughes]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Robert" == Robert Dewar <dewar@merv.cs.nyu.edu> writes:
Robert> I know many programmers feel this way, but I certainly would
Robert> not hire them.  Pretty strong central management is essential
Robert> to software quality in my view.

Strong perhaps.  Numerous probably not.  Otherwise decisions much go
through too many levels and too many ``adjustments''.  Certainly when
your administrative staff outnumbers your programmers, you have a very
big problem.  More generally, when the overseers outnumber the
workers, large problems occur.  Unfortunately, this situation is far
more common than people give credit for.

I believe Parkinson had it right, in _Parkinson's_Law_and_Other_Studies_
_in_Administration_.  Administration grows without bound, and without
regard to the amount of work being done.
- -- 
Graham Hughes    http://A-abe.resnet.ucsb.edu/~graham/ -- MIME & PGP mail OK.
   PGP Key fingerprint = E9 B7 5F A0 F8 88 9E 1E  7C 62 D9 88 E1 03 29 5B

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMy3zqSqNPSINiVE5AQHMqgQArGUidoFa/cX0VYEzpGhXfsfqkWYyyo4W
76KR4xpVPzGwfx4F4uCZFtSV8lwOsG3ZGjgapxyg3INLbavsPblcGsQQAXYAjta7
dYRRwR1hBpBgiBIBEz6FsBz2jOu3u1OOhe0qVh/2Jg1kk/SFAYI3JVS9fUOyuXzM
9kAZvIPi8WM=
=jCZz
-----END PGP SIGNATURE-----

Re: Do I Really Need A Supervisor?

[Norman H. Cohen]

Its commonplace in newsgroups for a thread to drift to a new topic that
has nothing to do with the Subject: line.  But here we have someone's
lament about managerial incompetence, posted with the subject "Do I
Really Need A Supervisor" drifting to a discussion about whether Ada
programs require main subprograms--and the subject line remains
appropriate!!!! :-)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Do I Really Need A Supervisor?

[antialias]

Oh, heck, maybe it didn't belong on comp.lang.ada, but this
IS the kind of software engineering environment that Ada 
software is developed in...this article was also posted to
comp.arch.embedded and comp.software-eng...the comments are
pretty much the same on those groups, many agree that I (we)
don't need supervisors, but many try to defend the role of the
supervisor...hmmm, I wonder if these defenders are themselves
supervisors...

...but then there is this rather curious response which was 
emailed to me but not posted:

> Yes.  You absolutely need a supervisor. 
> 
> Let us assume that you are a very able software engineer, but there 
> is apparently a definite problem.  Maybe you do not convey any 
> confidence that you are capable of performing real work.  Do you 
> convey the idea that you are a mal-content, a trouble maker, of 
> technically questionable ability?
> 
> You state that you have a supervisor, that leads only two people. If
> that is true, that "well known aerospace firm" would not be profitable,
> for very long.  Is that level of supervision required because of your 
> behavior, your attitude?
> 
> As a software engineer, you need a "road map" to help in your design.
> A corporation needs a "road map" to define profitability.  The customer
> needs to know that your design will meet their needs.  Why are you so
> antagonistic towards individuals that are not software engineers?  
> 
> Your attitiude towards SEI shows me that you are not a very discplined
> engineer.  What are you trying ot hide?
> 
> A good software engineer desires supervision, to isolate them from the 
> corporate politics, to shelter them from the customer, etc.  A good 
> supervisor does not need to be as technically astute as yourself.  That 
> is why they are paying you.   
> 
> In my background, I have managed software engineers, a few as five and
> as many as thirty-five.  I am currently working, as a softweare engiunere, 
> in a contract position.  Why did I give up management, to return to 
> engineering?  This is fun, if there is a manager.  If not, I might
> as well return to the politics.
> 
> I hope that I never have the mis-fortune of working with you, or the
> horror of having you work for me.  I know I will never have to worry
> about working for you.
> 

Very strange, very,very strange...

Re: Do I Really Need A Supervisor?

[Randall Edick]

Richard Kenner wrote:
> 
> But now, it seems everybody is developing packages for it and there's
> all sort of incompatibily problem between (e.g.) versions of
> libc, binutils, and GCC, to say nothing of multiple different object
> file formats in use.
> 
> These problems are due to lack of a central management.

Thank you Richard for your work.  

Be careful what you wish for.  How many levels of management do you
want? How many project estimates do you want to do?  How much time do
you  want to spend explaining to * levels what it is you want to do, and
justifying it (explain for instance WHAT IS A COMPILER? and where do you
bolt it ON? before you proceed).

 I didn't mean to imply that all management is bad.  Certainly not. 
 The problem is that there are a LOT of people who want to be managers
and they all need a technical type i.e. donkey to justify it.  Once this
stuff starts it is VERY HARD TO STOP IT.  Linux/GNU is a juicy excuse
for bureacracy. When it happens it could kill it.   The saving grace
may be there not a lot of money in it.

I don't think you want a central management group.  You want a 
central TECHNICAL group.
-- 

===============================================================
Randall Edick                         
(I speak for myself)
================================================================

Re: Do I Really Need A Supervisor?

[Robert Dewar]

Jay Martin says

<<But, they have no idea in the world about how the work should get done
(otherwise, they'd be doing it themselves), so they try and inflict this
"process" which they've read about in magazines and seminars.... all
probably written/run by people who haven't ever written a line of code in
their lives.  And they think if this process is followed, then they can
feel secure in the fact that our product will be correct.  Instead, it
brings our overhead right back up to those of the big companies.  It
increases the life cycle, increases the cost... and depresses us coders.>>

Maybe we could entitle this the "hackers lament". Personally I would not
touch with a ten foot barge pole any organization whose programmers had
this attitude, sounds like SEI maturity level -1 at work :-)

Re: Do I Really Need A Supervisor?

[Randall Edick]

Robert Dewar wrote:
> 
> 
> I know many programmers feel this way, but I certainly would not hire them.
> Pretty strong central management is essential to software quality in my
> view.


What do you mean by strong? Knowledgeable in the technology,
knowledgeable in people skills.  What?

What is the quality  you see?  Does it happen to
be exactly the one you want to see?  Home much time is being
spent trying to create this image for you? Do you happen to
reward the people who produce this image?

What exactly is your contribution?  Lets hear it.  FACTS and DATA.
Nobody seems to know. 

Obviously people have some complaints here.  You've only 
responded with a remark aimed (obviously) to intimidate.

How about some content.
-- 

===============================================================
Randall Edick                   

================================================================

Re: Do I Really Need A Supervisor?

[Jay Martin]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Jay Martin says

><<But, they have no idea in the world about how the work should get done
>(otherwise, they'd be doing it themselves), so they try and inflict this
>"process" which they've read about in magazines and seminars.... all
>probably written/run by people who haven't ever written a line of code in
>their lives.  And they think if this process is followed, then they can
>feel secure in the fact that our product will be correct.  Instead, it
>brings our overhead right back up to those of the big companies.  It
>increases the life cycle, increases the cost... and depresses us coders.>>

>Maybe we could entitle this the "hackers lament". Personally I would not
>touch with a ten foot barge pole any organization whose programmers had
>this attitude, sounds like SEI maturity level -1 at work :-)

Actually the above was written by:
"deco" <abby@augustschell.com.diespamdiediedie>.

Jay Martin

(Though I am sympathetic to calls to shoot managers who can't
"software engineer" their way out of bag making software "process"
decisions beyond their comprehension)

Re: Do I Really Need A Supervisor?

[Robert Dewar]

<<Obviously people have some complaints here.  You've only
responded with a remark aimed (obviously) to intimidate.>>

Well I understand that some people regard the idea of strong management
as intimidating, and that's fine, different people work in different ways.
All I am saying is that as far as I am concerned strong management is
essential to software quality. Even in such a minor aspect as coding
standards, if you have a bunch of "I don't need no stinkin' supervisor"
hackers, you will have trouble solving even this trivial problem (of
requiring consistent surface syntax).

Re: Do I Really Need A Supervisor?

[nasser]

In article <332E163F.5EFD@earthlink.net>, antialias@earthlink.net says...
>
>Oh, heck, maybe it didn't belong on comp.lang.ada, but this
>IS the kind of software engineering environment that Ada 
>software is developed in...

it is unfortunate to the Ada language that it happened to be  
mostly used in environments where zillion levels of managements 
and entrenched beaucracy (sp?) is the norm, this environment is a 
turn off for many programmers who would love otherwise to program 
in Ada but are wary of the surrounding working climate where Ada 
is used.
 
Nasser

Re: Do I Really Need A Supervisor?

[Robert Dewar]

<<Actually the above was written by:
"deco" <abby@augustschell.com.diespamdiediedie>.

Jay Martin>>

Sorry, I try to get attributions right, but sometimes it is easy to 
get confused!

Re: Do I Really Need A Supervisor?

[Robert Dewar]

Graham says

<<Strong perhaps.  Numerous probably not.  Otherwise decisions much go
through too many levels and too many ``adjustments''.  Certainly when
your administrative staff outnumbers your programmers, you have a very
big problem.  More generally, when the overseers outnumber the
workers, large problems occur.  Unfortunately, this situation is far
more common than people give credit for.

I believe Parkinson had it right, in _Parkinson's_Law_and_Other_Studies_
_in_Administration_.  Administration grows without bound, and without
regard to the amount of work being done.>>

Well I certainly agree that having too many management types around is
a big problem, but I am not sure that it is the biggest problem. In my
experience, the too-many-people syndrome is most serious at the technical
level. There are lots of projects where 90 low level people are desperately
struggling to do a bad job of implementing a system which 10 really good
people could do in a fraction of the time.

Very often this is the result of a beaurocratic structure which has no
problem in hiring hundreds of people and paying them $50,000, but recoils
in horror at the idea of replacing dozens of such low level people with
one really competent person and paying them what they are worth.

I certainly see this phenomenon at work in negotiating T&M rates with
the government. Very often you are in the position of saying:
if we charge $50 an hour, then we need to do this with low level people,
and the total cost will be $x. If we charge $200 an hour, then we can
do this with competent people and the charge will be $y. But often the
govt will prefer the $50 to the $200, even if $x is way bigger than $y.
Why is this choice made -- well obviously to hold costs down, $200 is
much too much! :-)

Re: Do I Really Need A Supervisor?

[John Apa]

antialias@earthlink.net wrote:
> 
> Oh, heck, maybe it didn't belong on comp.lang.ada, but this
> IS the kind of software engineering environment that Ada
> software is developed in...this article was also posted to
> comp.arch.embedded and comp.software-eng...the comments are
> pretty much the same on those groups, many agree that I (we)
> don't need supervisors, but many try to defend the role of the
> supervisor...hmmm, I wonder if these defenders are themselves
> supervisors...
> 
> ...but then there is this rather curious response which was
> emailed to me but not posted:
> 
> > Yes.  You absolutely need a supervisor.

snip

> > I hope that I never have the mis-fortune of working with you, or the
> > horror of having you work for me.  I know I will never have to worry
> > about working for you.
> >
> 
> Very strange, very,very strange...

Not so strange. Realistic. Our industry will never gain the respect it
deserves as long as we are seen as code hacks. If we are to be
considered _engineers_ then we'd better start adopting some of the tried
and true methods of design. SEI may not be a magic bullet, but I'd
rather work at a company that is trying to improve than someplace that
just doesn't care. I enjoy solving problems, but I hate having to play
the politics game. I have supervisors to take care of that. Systems are
getting to complex to hack together over a weekend, at least the ones I
work on, and that means that more people are involved. The more people,
the more communication and coordination is required.

Four years ago, I was firmly against the "process" improvement and TQM
plans. But somewhere along the ines I realized that the reason I had
problems, was because it was being implemented poorly. Now I'm at a
company that is trying to do things right, and it's great. I'm free to
design and develop my software, without having to deal with all the BS
politics that goes on. Beyond that, the code we develop is more reliable
and maintainable. Part of having a process that works, is having good
people who maintain their technical edge. That means more training in
modern methods and tools. That is a good thing. 


-- 



***********************************
Standard Disclaimer Applies...
John Thomas Apa
Honeywell Defense Avionics Systems
Albuquerque, New Mexico.
***********************************

Re: Do I Really Need A Supervisor?

[Michael F Brenner]

Robert Dewar sayeth:
    > All I am saying is that as far as I am concerned strong management is
    > essential to software quality. Even in such a minor aspect as coding
    > standards, if you have a bunch of "I don't need no stinkin' supervisor"
    > hackers, you will have trouble solving even this trivial problem (of
    > requiring consistent surface syntax).

Here is one possible solution to the problem of requiring consistent surface
syntax: Dont. Instead, set a pretty-printer to different parameters (font,
indenting, capitalization, commenting, color, etc.) each time the code is
looked at. This finds problems that may be missed in a consistent syntax 
environment. Problems, such as one extra alias of the variable causing
the error, or programs that have too high an opinion of their looks :)

Re: Do I Really Need A Supervisor?

[Robert Dewar]

Michael Breenner says

<<Here is one possible solution to the problem of requiring consistent surface
syntax: Dont. Instead, set a pretty-printer to different parameters (font,
indenting, capitalization, commenting, color, etc.) each time the code is
looked at. This finds problems that may be missed in a consistent syntax
environment. Problems, such as one extra alias of the variable causing
the error, or programs that have too high an opinion of their looks :)>>


Given the smiley at the end  it is hard to know if this is a serious suggestion.
If so, it does not work for a number of reasons, and we have a long thread on
this topic only a few months ago, so it is too early to repeat it!

Re: Do I Really Need A Supervisor?

[antialias]

John Apa wrote:

> SEI may not be a magic bullet, but I'd rather work at a 
> company that is trying to improve than someplace that
> just doesn't care. 

Some are getting the idea that I am a depraved undisciplined
malcontent and that I work for an extermely backwards client
who is about to go under. I may be depraved, but I assure you
not undisciplined in my field. My client is one of the leaders
in the field - I choose not to reveal the corp's name but it
is one of the top three defense orgs...

SEI may have some very good ideas about how to develop software.
Unfortunately, these ideas are implemented my morons who do
not know how to develop the software they are writing development
policies for. As I stated, ny work at the moment is to write
a safety critical device which needs about 15,000 lines of code
to run on a 68332...an easy job if it weren't for doing things
"by the process" - which requires us to do things like vax based
unit testing instead of target based, using tools to measure and
record metrics which nobody uses, maintaining our code and all the
related files in an archaic word processing system, using a pretty
printer which makes my beautifully organized source code into 
an absolute mess...etc, etc, etc...  our company is having a hard
time keeping software engineers because of the "process" they
have to work under...

Re: Do I Really Need A Supervisor?

[jim hopper]

Its been my experience that people get this kind of managment and
implementation of the SEI process in organizations where the software
engineering staff is to busy to be bothered being part of the process
groups who write the standards and processes.  

At our shop in Dayton at SAIC we run at level 3 (though a number of us
have worked for the last 5 months as part of the team in a primes level
5 program) and i made it a point to be part of the process of defining
our procedures and standards, and to push our other tech people to
particpate as well.  Our engineering procedures were written 100% by
working engineers, not managers.  our Software Development Plans for
projects are written mostly by the development staff who have to
implement them, not by "managers".  Mostly what we did when writing our
plans and procedures is sit down and document how we did business.  We
were pretty much doing the correct thing all along, but by writing it
down and thinking about it we cleaned it up, and made it into something
we can teach new folks etc.  

while we sometimes can do stupid things, and i am the first to rant
about managers (i am a leader NOT a manager to paraphrase a Dilbert
cartoon i like) we have procedures and standards that i consider very
resonable. And most of our software staff feels so as well. Process is
not imposed from above its part of how we do things!

I submit your problem is probably not your management so much, as your
attitude that you are to busy to be bothered with helping to defining
your process.


best jim



In article <3330BE71.695@earthlink.net>
antialias@earthlink.net writes:

> SEI may have some very good ideas about how to develop software.
> Unfortunately, these ideas are implemented my morons who do
> not know how to develop the software they are writing development
> policies for. As I stated, ny work at the moment is to write
> a safety critical device which needs about 15,000 lines of code
> to run on a 68332...an easy job if it weren't for doing things
> "by the process" - which requires us to do things like vax based
> unit testing instead of target based, using tools to measure and
> record metrics which nobody uses, maintaining our code and all the
> related files in an archaic word processing system, using a pretty
> printer which makes my beautifully organized source code into 
> an absolute mess...etc, etc, etc...  our company is having a hard
> time keeping software engineers because of the "process" they
> have to work under...

Re: Do I Really Need A Supervisor?

[Corey Minyard]

"David Taylor" <dtaylor@iquest.com> writes:

> 
> In article <33285CC6.1CFB@ss5010.ca.boeing.com>, Randall Edick
> <rre9518@ss5010.ca.boeing.com> wrote:
> 
> >Jay Martin wrote:
> >> 
> >> Auntie Alias <antialias@earthlink.net> writes:
> >> 
> >> >Do I Really Need A Supervisor?
> >> 
> >> >I work for a well known aerospace firm developing embeddded
> [[snip]]
> >SAY IT BROTHER.  
> >
> >Please see the other items I posted today. I'm fed up with this
> >nonsense, and I'm telling my supervision.
> >
> >Where would we be without managment?  An excellent example is
> >Linux.  NO MANAGEMENT.  One of the largest, most complex, best
> >technical, best selling efforts of all time.  All done by techies
> >over the internet.
> 
> Another example is the Internet itself. There is no one "in charge". There
> is some real crap on the Internet, but there is a lot of real genius.
> 
> dave

The Internet, well I don't know, but it is not a software development
project, either

I would argue that Linux does have management.  We have Linus at the
helm and then a host of other people responsible for various things
and then a host of developers who feed into them.  The question is not
whether management exists (can you image one huge CVS repository with
everybody making changes in it) but the quality of management.  Linux
has rather defacto management and they are all technical and
interested in technical issues and "doing the right thing" (very
little if any politics).  Therefore they produce a very high quality
technical product.

So the problem is not management (which I would argue is impossible to
work without), but it is human nature (or "sin nature" as Christians
call it, which is a better description IMHO).  Somehow Linux has
largely avoided it.  NetBSD and FreeBSD haven't avoided it and Linux
passed them by.  Any organization that can avoid it will do very well,
but I have never seen one that has that has reached any size at all.

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

Re: Do I Really Need A Supervisor?

[Michael F Brenner]

    > People get this kind of managment ... of the SEI process in 
    > organizations where the software engineering staff is to busy 
    > to be bothered being part of the process groups who write the 
    > standards and processes.

This is truly the main problem with implementing the SEI model. We should
document the process at it really is. Then slowly evolve some improvements.
Too many organizations document processes as some process group wishes
the processes to be. The activities in a process should only require
steps that are the most economical way to produce the desired quality in
the product. Those metrics which help you attain this economy are the
ones that should be measured automatically, rather than measuring what
is easy to measure. For example, at software maintenance time you are
mainly interested in cohesion, coupling, and the number of bugs inserted
by the maintainers, which are harder to measure than SLOC, and McCabe
number of test paths. But SLOC and McCabe are easy to measure, so many
measure them, and wonder why they continue to introduce bugs at the same
rate. 

Re: Do I Really Need A Supervisor?

[John Apa]

nasser@apldbio.com wrote:
> 
> In article <332E163F.5EFD@earthlink.net>, antialias@earthlink.net says...
> >
> >Oh, heck, maybe it didn't belong on comp.lang.ada, but this
> >IS the kind of software engineering environment that Ada
> >software is developed in...
> 
> it is unfortunate to the Ada language that it happened to be
> mostly used in environments where zillion levels of managements
> and entrenched beaucracy (sp?) is the norm, this environment is a
> turn off for many programmers who would love otherwise to program
> in Ada but are wary of the surrounding working climate where Ada
> is used.
> 
> Nasser

My apologies but:
RUBISH!

Are you trying to tell me that
c/basic/pascal/ST/effiel/cobol/asm/fortran programmers don't have as
much management? Absolute rubbish.

More likely people who are turned off by Ada haven't done their
homework. Statements such as the above do nothing to encourage people to
investigate on their own. Ada95 is no magic bullet, but it gives the
engineer a great deal of power, flexibility, and scalability. True, Ada
is not for everyone. It's unfortunate that compilers don't exist for
every platform, but look at the good work being done by GNAT in getting
good compilers out for many platforms. An excellent product and value.

If you're picking a language for a project based on the type of
management it may or may _not_ spawn, then I hope I never have to deal
with your product. You should choose your language based on it's merits
and ability to solve your particular problem. I though we all learned
that in school.

I've read the LRM and the Rationale, I choose Ada95.
-- 
***********************************
Standard Disclaimers Apply
John Thomas Apa
Honeywell Defense Avionics Systems
Albuquerque, New Mexico.
***********************************

Re: Do I Really Need A Supervisor?

[antialias]

[-- Attachment #1: 032197.txt --]
[-- Type: text/plain, Size: 4111 bytes --]



Do I Really Need A Supervisor: 
My Observations of My Supervisors

Has my supervisor been a help or a hindrance to the projects 
I have been on? Below, as an example of one software engineer's
experience I summarize the project and the supervisor's role
and render my opinion as to the supervisor's helpfulness.
Finally, a comment for each as to whether I could have done 
better with or without that supervisor.

I begin my career ten years ago:

An IRAD project studying Ada in multiprocessor 1750A runtime
system implementations. The supervisor was a physics major,
did not know Ada, had about three years experience programming
embedded fortran. Was not very helpful. Was needed though, 
because I and my coworkers were inexperienced.

A missile guidance subsystem in 1750A Ada. The supervisor was 
also a physics major. Did not know Ada, but learned quickly.
Did not know how to organize the project. Skipped unit testing
went straight to big bang testing, costing us an extra year
of effort. Was so-so as a supervisor. I could have done better 
if he had been more of a leader.

A multiprocessor missile guidance system in TMS320C30 and R3000
Ada. The supervisor was a math major. Did not know Ada. Did not
care to learn. Mismanaged the project. Project was cancelled by
the Air Force and given to our competitors. The supervisor's
poor decisions were a major reason the project was cancelled.
Would have been much better without her.

A multiprocessor electronic warfare system in 68040 Ada. The 
supervisor knew Ada. Was an EE with a field service engineer
background. Was technically bright, aggressive at resolving
problems. Spent little time in meetings, a lot of time working
on the system. Was very helpful. Was better with him.

An avionics test system in 68040 Ada. The supervisor was a
chemical engineer who knew a lot of PC buzz words. Was totally
technically incompetent. Hired me to fix a problem which took
me half an hour to fix. Had me work on it for four months. Was
totally useless and a considerable hindrance to the project.
The company would have been better without this supervisor.

An avionics display system in R3000 Ada. The supervisors (two)
were software people. They spent a lot of time arguing with the
upper management. When they weren't arguing, they were helpful.
I could have gotten the job done without them though.

A MIS system in Ada. Three supervisors: A former B-52 pilot who
had an HR degree, and two federal employees who were software
people. The bomber pilot was dead weight, but a barrel of fun
to have around. The other two were competent, but unable to
convey what in the world it was that we were supposed to be
developing. They managed a staff of twelve, most of which
sat around and did nothing useful (one was in charge of 
monitoring our software reuse. Another was tasked with developing
a string manipulation library. Others had no apparent function).
The whole project was useless. I fled from it after three months.

A tank software system in C. The supervisor was an EE. Was
very helpful, but by and large I was left to develop the
software for my box on my own, so I guess I didn't really 
need him to be a supervisor. 

An electronic warfare system in Ada. The supervisor does not
know Ada. Does not have time to do software development. Barely
knows what it is that I am working on. I could do the job better
on my own. 

So there you have my opinions. I think I am better off if the
supervisor is highly technically competent and smart enough to
discard/ignore/hand off the useless management stuff and focus
instead on getting software developed. I think I am worse off if
I have someone over me who does not know or care about what I
am doing and who hides their technical incompetence by burying
themselves in management work - meetings, tracking, spreadseets,
paperwork, metrics, statistics. It is the software that 
matters, who should care about anything else? Produce software
that passes the tests, and no one really needs all this supervision
and management. 

Save time, save money - reduce supervision of software engineers.

Re: Do I Really Need A Supervisor?

[John G. Volan]

Robert Dewar wrote (quoting Randall Edick):
> 
> I don't think you want a central management group.  You want a
> central TECHNICAL group.>>
> 
> I know many programmers feel this way, but I certainly would not hire them.
> Pretty strong central management is essential to software quality in my
> view.

Robert, to co-opt one of your favorite words, I think you're _confusing_
two distinct notions: "management" and "technical leadership."

By "management" I mean the sort of people described in poor Auntie
Alias' tirade: Beaurocrats who all too frequently have little or no
technical expertise but who, by virtue of their MBAs, hold the reigns of
power in an organization. At their best, they enable the technical staff
to do their jobs efficiently, at their worst they waste the
organization's energy with political empire-building. In either case,
they contribute very little indeed to the actual technical content of
the organization's product.

But "technical leadership" is something altogether different. A
technical leader is someone who is both "technical" -- contributing
substantially to the actual technical content of the product -- and also
a "leader" -- someone who provides the architectural vision that unifies
the technical product, and who willingly takes on and bears the
responsibility for enforcing/promoting/preserving/extending that vision.

There are many great examples of this latter notion even just within
this newsgroup. Certainly the honorable Messrs. Stallman and Kenner of
GNU fame fall into this category. The team leaders on the Ada83 and
Ada95 projects, Jean Ichbiah and Tucker Taft, are classic examples.  And
of course, let's not forget RBKD himself.

With managers, you're lucky if you just "manage" to get your software
built. But I'd wager that, behind every truly excellent piece of
software you can name, you can name a strong technical leader
responsible for it.

I say, let us have more people of the latter sort, and heaven spare us
from the former! :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were mever defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

P.S. Which category do you think Bill Gates would fall into...?

Re: Do I Really Need A Supervisor?

[John G. Volan]

Robert Dewar wrote (quoting Randall Edick):
> 
> I don't think you want a central management group.  You want a
> central TECHNICAL group.>>
> 
> I know many programmers feel this way, but I certainly would not hire them.
> Pretty strong central management is essential to software quality in my
> view.

Robert, to co-opt one of your favorite words, I think you're _confusing_
two distinct notions: "management" and "technical leadership."

By "management" I mean the sort of people described in poor Auntie
Alias' tirade: Beaurocrats who all too frequently have little or no
technical expertise but who, by virtue of their MBAs, hold the reigns of
power in an organization. At their best, they enable the technical staff
to do their jobs efficiently, at their worst they waste the
organization's energy with political empire-building. In either case,
they contribute very little indeed to the actual technical content of
the organization's product.

But "technical leadership" is something altogether different. A
technical leader is someone who is both "technical" -- contributing
substantially to the actual technical content of the product -- and also
a "leader" -- someone who provides the architectural vision that unifies
the technical product, and who willingly takes on and bears the
responsibility for enforcing/promoting/preserving/extending that vision.

There are many great examples of this latter notion even just within
this newsgroup. Certainly the honorable Messrs. Stallman and Kenner of
GNU fame fall into this category. The team leaders on the Ada83 and
Ada95 projects, Jean Ichbiah and Tucker Taft, are classic examples.  And
of course, let's not forget RBKD himself... :-)

With managers, you're lucky if you just "manage" to get your software
built. But I'd wager that, behind every truly excellent piece of
software you can name, you can name a strong technical leader
responsible for it.

I say, let us have more people of the latter sort, and heaven spare us
from the former! :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were mever defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

P.S. Which category do you think Bill Gates would fall into...?

Re: Do I Really Need A Supervisor?

[John G. Volan]

Robert Dewar wrote (quoting Randall Edick):
> 
> I don't think you want a central management group.  You want a
> central TECHNICAL group.>>
> 
> I know many programmers feel this way, but I certainly would not hire them.
> Pretty strong central management is essential to software quality in my
> view.

Robert, to co-opt one of your favorite words, I think you're _confusing_
two distinct notions: "management" and "technical leadership."

By "management" I mean the sort of people described in poor Auntie
Alias' tirade: Beaurocrats who all too frequently have little or no
technical expertise but who, by virtue of their MBAs, hold the reigns of
power in an organization. At their best, they enable the technical staff
to do their jobs efficiently, at their worst they waste the
organization's energy with political empire-building. In either case,
they contribute very little indeed to the actual technical content of
the organization's product.

But "technical leadership" is something altogether different. A
technical leader is someone who is both "technical" -- contributing
substantially to the actual technical content of the product -- and also
a "leader" -- someone who provides the architectural vision that unifies
the technical product, and who willingly takes on and bears the
responsibility for enforcing/promoting/preserving/extending that vision.

There are many great examples of this latter notion even just within
this newsgroup. Certainly the honorable Messrs. Stallman and Kenner of
GNU fame fall into this category. The team leaders on the Ada83 and
Ada95 projects, Jean Ichbiah and Tucker Taft, are classic examples.  And
of course, let's not forget RBKD himself... :-)

With managers, you're lucky if you just "manage" to get your software
built. But I'd wager that, behind every truly excellent piece of
software you can name, you can name a strong technical leader
responsible for it.

I say, let us have more people of the latter sort, and heaven spare us
from the former! :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were mever defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

P.S. Which category do you think Bill Gates would fall into...?

Re: Do I Really Need A Supervisor?

[John G. Volan]

(Apologies to all if this already went out, had some problems with my
news/mail settings...)

Robert Dewar wrote (quoting Randall Edick):
> 
> I don't think you want a central management group.  You want a
> central TECHNICAL group.>>
> 
> I know many programmers feel this way, but I certainly would not hire them.
> Pretty strong central management is essential to software quality in my
> view.

Robert, to co-opt one of your favorite words, I think you're _confusing_
two distinct notions: "management" and "technical leadership."

By "management" I mean the sort of people described in poor Auntie
Alias' tirade: Beaurocrats who all too frequently have little or no
technical expertise but who, by virtue of their MBAs, hold the reigns of
power in an organization. At their best, they enable the technical staff
to do their jobs efficiently, at their worst they waste the
organization's energy with political empire-building. In either case,
they contribute very little indeed to the actual technical content of
the organization's product.

But "technical leadership" is something altogether different. A
technical leader is someone who is both "technical" -- contributing
substantially to the actual technical content of the product -- and also
a "leader" -- someone who provides the architectural vision that unifies
the technical product, and who willingly takes on and bears the
responsibility for enforcing/promoting/preserving/extending that vision.

There are many great examples of this latter notion even just within
this newsgroup. Certainly the honorable Messrs. Stallman and Kenner of
GNU fame fall into this category. The team leaders on the Ada83 and
Ada95 projects, Jean Ichbiah and Tucker Taft, are classic examples.  And
of course, let's not forget RBKD himself... :-)

With managers, you're lucky if you just "manage" to get your software
built. But I'd wager that, behind every truly excellent piece of
software you can name, you can name a strong technical leader
responsible for it.

I say, let us have more people of the latter sort, and heaven spare us
from the former! :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were mever defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

P.S. Which category do you think Bill Gates would fall into...?

Re: Do I Really Need A Supervisor?

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>Well I understand that some people regard the idea of strong management
>as intimidating, and that's fine, different people work in different ways.

I think the major difference here is that when Robert Dewar says "strong
management is essential to software quality" he means strong COMPETENT
management, where competence is part of what it _means_ to be "strong".

Take, for example, a software project I recently heard of.
The organisation developed a web-based tool to be used at two sites.
The tool was "tested" and passed by the manager.
Trouble was, it was only tested at one site.
It caused chaos at the other site, which, having had X-terminals for
longer than the first site, had a lot of black-and-white ones.
The tool had never been tested on black-and-white boxes.

The development team were rather sarcastic about people being so stupid
as to use black and white machines, and the "foreman" who screamed about
the problem was told that he shouldn't be admitting to the users that
there was any problem.  He kept screaming and eventually a black-and-
white version was provided.

Was that strong management?  Well, the users were given absolutely no
alternative to using the tool.  And the "foreman" felt threatened by
the attitude of the developers.  So that is very like the kind of
situation that other people have been describing.

But it's not at all like the kind of situation Robert Dewar has in mind,
I believe.  I think he would say that management which doesn't ensure
that the tool is tested on _all_ the platforms the users are forced to
use it on is not strong in the sense he has in mind, however forceful
it may be.

_Forceful_ but technically incompetent management is not only not
essential to software quality, it is inimical to it.  (And technical
competence here means competence _appropriate to the level of
management_; I don't think a manager needs to be able to cut code in
the language the project is using, but the manager _does_ need to
understand the _software engineering_ issues.)
-- 
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Do I Really Need A Supervisor?

[Robert Dewar]

<<By "management" I mean the sort of people described in poor Auntie
Alias' tirade: Beaurocrats who all too frequently have little or no
technical expertise but who, by virtue of their MBAs, hold the reigns of
power in an organization. At their best, they enable the technical staff
to do their jobs efficiently, at their worst they waste the
organization's energy with political empire-building. In either case,
they contribute very little indeed to the actual technical content of
the organization's product.

But "technical leadership" is something altogether different. A
technical leader is someone who is both "technical" -- contributing
substantially to the actual technical content of the product -- and also
a "leader" -- someone who provides the architectural vision that unifies
the technical product, and who willingly takes on and bears the
responsibility for enforcing/promoting/preserving/extending that vision.
>>

Well your definition of management is highly peculiar. No, I am not mixing
up these two concepts, not the way I use the terms. Technical leadership
is indeed an important managerial skill.

You are equating management with incompetent management, and you read
the word negatively. I don't!

Re: Do I Really Need A Supervisor?

[Robert Dewar]

Richard O'Keefe said

<<I think the major difference here is that when Robert Dewar says "strong
management is essential to software quality" he means strong COMPETENT
management, where competence is part of what it _means_ to be "strong".>>

Plus lots of other (iin my view) exactly appropriate observations.

Yes, indeed when I say someone is a strong chess player, I mean he is good
at playing chess, not that he can break his opponents neck with a single
karate chop. So, yes strong here is almost a synonym for competence.

I do see the confusion, in that people can easily use the phrase strong
management to refer to intrusive and inflexible management. In fact the
job of a competent manager is to make everything work smoothly without
being seen to be intrusive or inflexible, much as a good teacher following
the Socratic method guides the discussion of a class, without being seen
to be dictating it.

Re: Do I Really Need A Supervisor?

[Jon S Anthony]

In article <dewar.859025748@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Well your definition of management is highly peculiar. No, I am not mixing
> up these two concepts, not the way I use the terms. Technical leadership
> is indeed an important managerial skill.

Do you believe it a necessary skill for "good" management (in this
sort of area)?

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Do I Really Need A Supervisor?

[the one and only real true kibo]

-----BEGIN PGP SIGNED MESSAGE-----

On 22 Mar 1997 15:08:33 -0500 in article <dewar.859061288@merv> posted to comp.lang.ada, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> Richard O'Keefe said

> <<I think the major difference here is that when Robert Dewar says "strong
> management is essential to software quality" he means strong COMPETENT
> management, where competence is part of what it _means_ to be "strong".>>

> Plus lots of other (iin my view) exactly appropriate observations.

> Yes, indeed when I say someone is a strong chess player, I mean he is good
> at playing chess, not that he can break his opponents neck with a single
> karate chop. So, yes strong here is almost a synonym for competence.

> I do see the confusion, in that people can easily use the phrase strong
> management to refer to intrusive and inflexible management. In fact the
> job of a competent manager is to make everything work smoothly without
> being seen to be intrusive or inflexible, much as a good teacher following
> the Socratic method guides the discussion of a class, without being seen
> to be dictating it.

If you weren't a tenured professor, if you had a supervisor, you'd be
fired for sure.  Lose some weight - you look like a fucking pig.

I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
Finger me for my PGP public key. Check out my home page for the coolest
way to vote on new newsgroup proposals or to issue Usenet cancels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMzXqN6lPvImbzLKZAQGIrwP/Wua4TnWRilwKwhxPuVBkw2qjyL8d1VRk
mJDEinU3s1Ke9xm6rWofWxyP0v0vVM+OuCh1KOTLzJRd7QIe6IaoLjCBxiqQaf5K
GmrE4DxKNthZ8q3d/GbymzTDSKNSoYItNDA1/CHYqbgc2V++2wQRda8Mq7PQ0sPc
4yEp5QlDjOA=
=bsaQ
-----END PGP SIGNATURE-----

Re: Do I Really Need A Supervisor?

[L. Darrell Ray]

In article <JSA.97Mar24144925@alexandria>, jsa@alexandria (Jon S Anthony) says:
>
>In article <dewar.859025748@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
>> Well your definition of management is highly peculiar. No, I am not mixing
>> up these two concepts, not the way I use the terms. Technical leadership
>> is indeed an important managerial skill.
>
>Do you believe it a necessary skill for "good" management (in this
>sort of area)?
>
>/Jon
>
>-- 
>Jon Anthony
>Organon Motives, Inc.
>Belmont, MA 02178
>617.484.3383
>jsa@organon.com
>

I'm not the poster but I will give my opinion (as if anyone who knew
ever expected me to *not* give my opinion :-).

A first line engineering manager does *not* have to be technically 
great but needs a good general understanding of the relavant technologies
and of good engineering practices.  But IMO does *NOT* need to be, and it
is often better if the manager is not, the technical lead.  
The need for direct knowledge of a technology (but not of a general 
understanding of possiblities) decreases as the management level increases.

What managers need and is most often missing in practice is people and 
management skills.   A *good* manager can seem to have had no effect on 
the project *unless* you look for what they have done because they prevent
problems. 

Re: Do I Really Need A Supervisor?

[duncan]

> A first line engineering manager does *not* have to be technically
> great but needs a good general understanding of the relavant technologies

A speaker at our local ACM chapter was discussing this very issue last evening.
He suggested that having a manager who THINKS s/he is technically astute, but
who is not, is the worst situation.  This is followed by the manager who is
astute and likes to debate with the leads on the project about such issues
while the project mangament gets second billing.  Finally, there is the man-
ager who is not technically astute, knows it, and develops a trust relationship
with the lead folks who are knowledgable and sees to their "care and feeding"
as part of the project management effort.

This discussion was not restricted to software-only projects and the speaker
indicated the latter is what he has preferred throughout his career and how he
behaves in his role as a VP of project planning/management for his firm.

> and of good engineering practices.

The discussion did not make a distinction between specific technology and general
engineering knowledge, but I would say a manager should have the latter more than
the former since managing projects (and the people associated with them) does re-
quire more than just "people skills."  However, I do agree with the speaker that
it does not require a person who can do the individual technical jobs.

There is a danger in the latter if the manager, besides not being able to do the
technical work, is also not good with people and/or engineering knowledge of any
kind.

At the recent SEPG Conference, Rick Selby spoke about his work with Microsoft
and noted that first-line managers there are expected to develop code.  But I
gathered that the project/feature groups there are all very small (<10 people
including associated test personnel) and that project management is rather informal
anyway.

Re: Do I Really Need A Supervisor?

[Robert Dewar]

iDarriel says

<<A first line engineering manager does *not* have to be technically
great but needs a good general understanding of the relavant technologies
and of good engineering practices.  But IMO does *NOT* need to be, and it
is often better if the manager is not, the technical lead.>>

Well terminology can get in the way of this discussion, but to me the
technical lead *is* a manager, because they need to make management
decisions. Someone has to make technical decisions on overall design
and style. Sure these decisions can be reached by a consensus process,
but that is always part of a good management style, but someone does
ultimately have to make the decisions!

Re: Do I Really Need A Supervisor?

[Michael Malak]

In article <dewar.859473116@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>iDarriel says
>
>Well terminology can get in the way of this discussion, but to me the
>technical lead *is* a manager, because they need to make management
>decisions. Someone has to make technical decisions on overall design
>and style. Sure these decisions can be reached by a consensus process,
>but that is always part of a good management style, but someone does
>ultimately have to make the decisions!

There is overlap between the roles of the project manager and the
technical lead.  For a complete discussion, see Steve McConnell's
_Rapid Development: Taming Wild Software Schedules_ (Microsoft Press,
(c) 1996, ISBN 1-55615-900-5), p.314.

The technical lead makes the technical and design decisions as you
said.  But the project manager has different responsibilities:
communicating with upper management, allocating physical resources.

Depending on the situation, there are responsibilites which are
shared by the two roles, such as generating and enforcing schedules.

-- 
Michael Malak         Magic forwarding e-mail address:
Washington, DC        malak@acm.org

Re: Do I Really Need A Supervisor?

[Larry Kilgallen]

In article <dewar.859473116@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> iDarriel says
> 
> <<A first line engineering manager does *not* have to be technically
> great but needs a good general understanding of the relavant technologies
> and of good engineering practices.  But IMO does *NOT* need to be, and it
> is often better if the manager is not, the technical lead.>>
> 
> Well terminology can get in the way of this discussion, but to me the
> technical lead *is* a manager, because they need to make management
> decisions. Someone has to make technical decisions on overall design
> and style. Sure these decisions can be reached by a consensus process,
> but that is always part of a good management style, but someone does
> ultimately have to make the decisions!

I have run into a lot of companies where the technical leads are
quite specifically moved out of the "management" hierarchy and
restricted to only dealing with technical matters.  For others
in the company, that doesn't really count as "management" since
there is no direct authority for budgets and personnel matters.

It can actually work really well, with the "manager" repeating
back to the larger organization in "manager-speak" the results
of those technical decisions, including schedules and feature-
level conflicts.

If the greater "management" hierarchy wants exclusive use of
that word, it should be fine, just so the process works. While
terminology, as Robert points out, can be a barrier, this is
one time where "giving in" to the greater corporate culture
should be acceptable. It saves semantic energy for c.l.a talk
about "illegal" vs. "erroneous" vs. "shoddy", etc. :-)

Larry Kilgallen

Re: Do I Really Need A Supervisor?

[Laurent Guerby]

> There is overlap between the roles of the project manager and the
> technical lead.  For a complete discussion, see Steve McConnell's
> _Rapid Development: Taming Wild Software Schedules_ (Microsoft Press,
> (c) 1996, ISBN 1-55615-900-5), p.314.

   BTW, happy reader plug-in: Code Complete (same author and editor)
is an interesting SE book which is focusing on SE pratice when it
comes to write a procedure (how to specify them, what is the good size,
documentation, constructs to use/avoid in some situation...). The book
talks about C, VB and ... Ada (83), and is a good source of advocacy
material for the last one (in Ada, you cannot do the bad thing, the
compiler is watching you... well not all the time ;-).


> Michael Malak         Magic forwarding e-mail address:
> Washington, DC        malak@acm.org

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Do I Really Need A Supervisor?

[BAT0000000]

No, but he need you!