Do I Really Need A Supervisor?
Jay Martin
Auntie Alias <anti...@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
Jay Martin
Auntie Alias <anti...@earthlink.net> writes:
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
Erik Tangen
What you really need is a secretary that is also the president and CEO
(and your wife). Then you might get the job done under budget.
If your brother or sister was your sales rep, and your mother-in-law was
your accountant, you'd have it made.
Ian.Mitchell
anti...@earthlink.net wrote:
<snip>
> 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.
The trend in software engineering is now towards an
iterative-incremental delivery cycle driven by user
feedback. This is best accomodated by small teams
who liase with clients (who determine requirements)
directly. The process still needs supervising, but
the role of the team supervisor is to facilitate good
communication between client and developers. The
role of higher level supervisors is to insulate the
developers from non-technical management issues, such
as politics.
This small-team approach does seem to offer better
results than projects that are conducted with deep
management structures. The major benefit is better
requirements capture and faster turnaround times.
We'll likely see pressure put on large organisations
to adopt management matrices such as these in order
to remain competitive. Apparently Microsoft use
this lean management strategy and rely heavily on
peer review rather than didactic supervision.
For detailed info you might like to check out
"Object-Oriented Rapid Prototyping" by S. Connell
& L. Shafer, Yourdon Press 1995. Also "Object
Solutions" by Grady Booch, Addison-Wesley 1996.
In the mean time you can reconcile your sorrows at:
http://www.unitedmedia.com/comics/dilbert/
Regards, Ian Mitchell
- Vigor Technology Inc.
-------------------------------------------
Ian Mitchell ia...@vigortech.com
http://osiris.sund.ac.uk/rpl
-------------------------------------------
sic biscuitus disintegrat
-------------------------------------------
Thomas Clark
cordinate the project and do some of the work usually on small teams (2
or 3).
I have found that a good manager / supervisor can handle 1 large team
doing a number of projects. A supervisor / managers job is to run
interferance for you so that you can get your job done. In a large
company this can be a full time job even for a small team. Just be
thankful that you don't have to do your job plus go to all of the
meeting that you supervisor / manager has to go to.
Thomas Clark
Randall Edick
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
rre...@es5031.ca.boeing.com
================================================================
Bob Kettig
In article <332805...@earthlink.net> ,
anti...@earthlink.net writes:
> ...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
Yep. That works [see Note 1]. Been doing it for many years.
Even better than getting out of the way is a manager who gives
you the ball and then blocks for you.
NOTE 1: Got to have the "right" people, of course. That's a
manager's most important job.
Perhaps a smaller (much smaller) organization would better
suit your needs. Engineering is not one homogeneous
experience wherever you go. It's niches, thousands of them.
Thanks for the entertaining and extremely relevant post. Best
of luck.
- Bob
Travis Griggs
Thank you for SOLIDLY reminding me why I no longer work in government
related industries. :)
--
Travis or Kerrin Griggs
Key Technology (509) 529-2161
t...@bmi.net (509) 527-8743
Stuart Park
: I work for a well known aerospace firm developing embeddded
: Ada software for a well known fighter aircraft. I have been
: 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.)
: 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,
This sounds like it belongs in a Dilbert book.. send it to Scott Adams
and you might find yourself immortalised in print. :)
--
Stuart Park Melbourne, Australia
Senior Analyst/Programmer E-mail: stu...@psd.com.au
Prometheus Software
Nicole Bianco
anti...@earthlink.net wrote:
> 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.
Any supervision you have should be doing the following:
- Provide adequate support so you can concentrate on the
software activities, not the scheduling, integration,
and pressure issues of the project
- Provide long term directions for the software organization
- Recognize when training is necessary for technical or
personal skills to assure success
- Assure that your environment is condusive to productivity
- Acquire and support the maintenance of tools which will
support your software organizational initiatives
- Define those initiatives
- Provide priorities of work so you are able to concentrate on
the highest pay-back efforts for the company
Oh, heck.. there are probably a lot more things.. but these I think are
pretty key. If your supervision is not performing these, or at least a
significant subset, then no.... you do not need them.
I would find it very difficult to manage a software group if I could not
personally identify with their issues. I would find it impossible to
establish the long term direction for the group as well. Although it is
not necessary to be an expert, the knowledge must (IMO) be there to
assure overall success.
One good point.... at least you do not have supervision who really wants
to be a technician, and micro-manages you!
It sounds to me that your organization is bound by itself.. ineffective
because of the depth of the organizations, and communication suffers due
to this chain of command and there is a good degree of incompetence
which is effecting your productivity.
Um.. how long you going to stay there?
Nicole
anti...@earthlink.net
Yes, there is a place for SOME managers and SOME supervisors.
I do not want to have to deal with contract administration or
configuration management or document publishing. These are things
which could be offloaded to others. But making decisions about
what to produce and how to produce it, that's my job. I can do
it better without supervisor interference.
anti...@earthlink.net
Thomas Clark wrote:
> Just be thankful that you don't have to do your job plus
> go to all of the meeting that you supervisor / manager
> has to go to.
My response is: I wouldn't go to them in the first place.
Most of the meetings that managers go to are total bullshit
wastes of time. Get rid of the supervisor AND the meetings.
anti...@earthlink.net
Nicole asks:
>
> Um.. how long you going to stay there?
>
I am a contract employee. I get paid by the hour and get to
come and go as I please. I recently tried to get my supervisor's
job - they turned me down as I cost too much. So I work at a
lower job at considerably more than my supervisor. I like the
task I have before me - the job would be ideal if I could just
GET RID OF THESE USELESS SUPERVISORS !!!
> Any supervision you have should be doing the following:
>
> - Provide adequate support so you can concentrate on the
> software activities, not the scheduling, integration,
> and pressure issues of the project
I can do these better along with my technical functions.
> - Provide long term directions for the software organization
I can do this better.
> - Recognize when training is necessary for technical or
> personal skills to assure success
I know what training I need. It is the supervisors who invariably
block my getting it.
> - Assure that your environment is condusive to productivity
I can do that better.
> - Acquire and support the maintenance of tools which will
> support your software organizational initiatives
TOOLS?!?! Oh PLEASE DON'T let these bozos decide what TOOLS we should
use!!! Oh, gosh, if you could see the disasterous selection of TOOLS
my client has forced on his people...
> - Define those initiatives
Don't need it.
> - Provide priorities of work so you are able to concentrate on
I know what needs to be done.
Thanks for your response - JCB
John Apa
Jay Martin wrote:
>
> Auntie Alias <anti...@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.
***********************************
David Taylor
In article <33285C...@ss5010.ca.boeing.com>, Randall Edick
<rre...@ss5010.ca.boeing.com> wrote:
>Jay Martin wrote:
>>
>> Auntie Alias <anti...@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
Psgooding
> >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
There is a lot of incompetance out there. IS directors, Project Managers,
Development Managers.
We work in a very immature industry. Less than 15%, maybe less than 10%
of
practitioners, or teams, or organizations, really know what they are
doing, or have
studied anything beyond the ends of their noses.
We work in an industry which has not figured out what the problem is, but
keeps
inventing more and more clever solutions. Software is people stuff, not
technical
stuff (my constant theme). To make it all work, you need talented people
who
understand that reality, and who know what to do about it.
Do you need a supervisor? Maybe not. But you do need a facilitator who
knows
how to build effective collaboration. You do need a bulldozer to get
organizational
and bureaucratic stuff out of the way. You need (as someone posted
earlier) someone
to go to all those damned meetings. You need somebody to be on your side
when
there is trouble. You need somone to hold up the gantt charts and BS
his/her way
through a management meeting so that you don't have to. You need someone
to
fight for the resources, the schedule, and the scope of the project.
Unfortunately, the percentage of people who can do these things is a small
subset
of the people who have those kinds of jobs. Therefore, like Dilbert, we
feel that most
supervisors are primarily carbon dioxide generators.
My solution? I hire my bosses carefully, and I demand a lot of them. If
they can't do
the job, I replace them. Exactly the same thing they think they are doing
with me.
Also, consider James Martin's statement in his recent book "The Great
Transition":
"Most of the systems being built today are the wrong systems." You need
a boss
who knows what that means, and what to do about it.
My favorite item from this thread: Bad boss? Give his phone number to a
headhunter.
One thing I've observed about these people: They have a good sense of
when to get
out. (Namely, right before the whole team figures out that the project is
doomed).
Their sense of self-preservation is our salvaltion. Bless their hearts.
Nobody needs a supervisor, but everybody needs a good boss. Find one,
hire that person
as your boss, and trust your instincts.
Richard Kenner
>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.
deco
Jay Martin <jma...@cs.ucla.edu> wrote in article
<5g7u24$1j...@uni.library.ucla.edu>...
: Auntie Alias <anti...@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?
...
:
: 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)
:
*sigh*
If it only was the government though...
I work for a very tiny software development company... we do custom
software for companies, sure we're just a bunch of hackers, really, but we
know how to get the job done... and we don't have the overhead of which you
speak.
The problem, then, comes from the customers (oh, but where would we be
without them?). Their staff doesn't have a clue how to develop the
products themselves because their programmers are of a completely different
mentality. So... they outsource. They want to use us because we can
develop software oh so much faster than all the big companies with all of
this bs overhead that the initial poster here speaks of.
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.
However, I think it's the same with the managers that are spoke of here.
Although, who can blame them? They don't trust the developers... we have
such a bad name (see the whole "good enough" topic in the "speed vs.
process" thread). So they have to try something. Just noone can seem to
come up with what that "something" is so they have us spend time preparing
pretty diagrams and giving presentations to un-technical people who don't
understand the diagrams anyways... rather than just coding.
Oh, I sometimes wish we really were "engineers" in the field of computer
"science"... if only this was a science, maybe things would be more precise
and trusting and we wouldn't have to put up with such bs.
abby
--
http://www.augustschell.com/abby
"Fantasy is a necessary ingredient in living, it's a way of looking
at life through the wrong end of a telescope. Which is what I do, and
that enables you to laugh at life's realities." -- Theodor Geisel
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)
================================================================
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.
Graham C. Hughes
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Robert" == Robert Dewar <de...@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-----
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 :-)
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
================================================================
Jay Martin
de...@merv.cs.nyu.edu (Robert Dewar) writes:
>Jay Martin says
Actually the above was written by:
"deco" <ab...@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)
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).
Robert Dewar
<<Actually the above was written by:
"deco" <ab...@augustschell.com.diespamdiediedie>.
Jay Martin>>
Sorry, I try to get attributions right, but sometimes it is easy to
get confused!
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! :-)
Robin Paterson
This is *complete* bollocks.
What you are saying here is that if management employ
hackers they should treat them like children.
The original poster was concerned that his skills
were being appraised by someone who knew *nothing*
about them (more or less).
You don't need _strong_ management.
You need _good_ employees and _good_ management.
"If you don't understand the issues you have no
business telling someone what to do about them."
This is the problem with many (most ?) current
software management scenarios.
'Rapid Development' by Steve McConnell.
It's a good read. If we all read it, then maybe we can
see where developers and managers can interact more
effectively, but both sides need to work *together*.
'Them and Us' is getting us all nowhere.
--
---+--- ---+---
Robin Paterson email: Robin.P...@dundee.NCR.COM
NCR Financial Systems Ltd. voice: 44 1382 592139 (GMT+0)
'End of the century'
---+--- ---+---
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 :)
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!
Chris Perrott
Robin Paterson wrote:
>
> Robert Dewar wrote:
> >
> > <<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.
> > 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).
>
>
> What you are saying here is that if management employ
> hackers they should treat them like children.
Certainly. Either fire them, or treat them like children till they
change
or quit.
--
Chris Perrott
Corey Minyard
"David Taylor" <dta...@iquest.com> writes:
>
> In article <33285C...@ss5010.ca.boeing.com>, Randall Edick
> <rre...@ss5010.ca.boeing.com> wrote:
>
> >Jay Martin wrote:
> >>
> >> Auntie Alias <anti...@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: min...@acm.org
Work: min...@nortel.ca UUCP: min...@wf-rch.cirr.com
Robin Paterson
Chris Perrott wrote:
>
> Robin Paterson wrote:
> >
> > What you are saying here is that if management employ
> > hackers they should treat them like children.
>
> Certainly. Either fire them, or treat them like children till they
> change or quit.
Hey.
What a _fantastic_ management plan.
Chris, you simply _must_ be a Product Manager.
Colin Goodall
Ya Know, I've been following this thread for a bit now and here's
how I see it.
Yes you do need a supervisor. But the problem is you need a _good_
supervisor. This leads us to the next problem...
"What is a Good Supervisor?"
A good supervisor is one which...
1) Gives you a clear definition of what needs to be accomplished.
2) Gets the resources you need to complete the job.
3) Stays the Hell out of your way once your working.
4) Shields you from dealing with the other idiot supervisors.
+--------------------------------------------------------------------+
| Colin Goodall | "A common mistake that people make when |
| goo...@magmacom.com | trying to design something completely |
| | foolproof is to underestimate the |
| | ingenuity of complete fools." |
| Opinions my own! | - Douglas Adams, "Mostly Harmless" |
+--------------------------------------------------------------------+
anti...@earthlink.net
Colin wrote:
> "What is a Good Supervisor?"
>
> A good supervisor is one which...
> 1) Gives you a clear definition of what needs to be accomplished.
> 2) Gets the resources you need to complete the job.
> 3) Stays the Hell out of your way once your working.
> 4) Shields you from dealing with the other idiot supervisors.
>
To which I say, "Amen." with emphasis on #3.
Anti
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.>>
>
> 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 => "john...@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...?
John G. Volan
of course, let's not forget RBKD himself... :-)
John G. Volan
John G. Volan
(Apologies to all if this already went out, had some problems with my
news/mail settings...)
Richard A. O'Keefe
de...@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.
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!
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.
the one and only real true kibo
-----BEGIN PGP SIGNED MESSAGE-----
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-----
Jon S Anthony
In article <dewar.859025748@merv> de...@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
j...@organon.com
L. Darrell Ray
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.
dun...@injersey.com
> 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.
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!
Michael Malak
In article <dewar.859473116@merv>, Robert Dewar <de...@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 ma...@acm.org
Larry Kilgallen
In article <dewar.859473116@merv>, de...@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.>>
>
> 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
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 ma...@acm.org
--
Laurent Guerby <gue...@gnat.com>, Team Ada.
"Use the Source, Luke. The Source will be with you, always (GPL)."