[comp.software-eng] Soft-Eng-Digest V1#1

soft_eng%mwvms@MITRE.ARPA (05/22/88)

--------
Received: From MWULTRIX(NIGAM) by MWVMS with RSCS id 2327
          for SOFT_ENG@MWVMS; Wed, 18 May 88 17:18 EDT
Full-Name: Alok Nigam
To: soft_eng%mwvms@mitre.arpa
Subject: Soft-Eng-Digest
From: soft-eng
Date: Wed, 18 May 88 17:14:48 EDT
Sender: nigam
     
Soft-Eng Digest             Tue, 17 Apr 88       V: Issue   1
     
Today's Topics:
                            Administrivia
                           Boswell (2 msgs)
             Boswell and the Project Chronicles (5 msgs)
                      Who builds tools? (2 msgs)
----------------------------------------------------------------------
     
Date: 17 May 88 13:20:04 EDT
From: nigam@mitre.arpa  (Alok C. Nigam)
Subject: Administrivia
     
Sorry about the long delay in getting this out.  The Soft-Eng
digest is now being distributed from a new site and it took a
while to get the administrative details worked out.  (I won't
really know until this goes out successfully, of course)
All submissions or administrative requests should be sent
to the following addresses:
     
               soft-eng@mitre.arpa
               soft-eng-request@mitre.arpa
            or nigam@mitre.arpa
     
I have a substantial backlog of messages so I will send out
a digest every day or so until I get through the messages.
After that I expect to send one out once or twice a week
depending upon the volume of submissions.
     
Any comments and/or suggestions are welcome.  I'd also
like to that Mark S. Day, who had been distributing this
digest until now.
     
------------------------------
     
Date: 3 May 88 00:00:58 GMT
From: tektronix!zeus!teklds!michaelo@ucbvax.Berkeley.EDU  (Michael O'Hair)
Subject: Boswell
     
This has less to do with Sofware Engineering than it does project
management, but read on if you like:
     
After surviving several real disasters, I'm of the opinion that a
"Boswell" should be assigned to every "major" project.  However,
my vision of a historian's role is to gather data for use by
management in preparing for future projects.  After a project is
completed, successful or not, the "project history" is collated
and presented to management, who will, hopefully, read it and learn
what went right and what went wrong.
     
The danger is that the historian can become viewed as a spy.  It would
be possible to do the data gathering as an "oral history" with anonymity
guaranteed to those who desire it.  The interviewers would have to be
trained at investigative techniques (journalism, not police) to be able
to filter out, or at least earmark, self-serving statements, ad hominem
attacks, and the like.
     
Ideally, each team would do their own history and list what they did
wrong and what they did right, giving opinions/reasons for each.  It
would take very secure people, however, to be able to write down "We
made a bad choice in personnel/algorithm/hardware/etc and here's what
it cost."  The bright side would be to be able to say "We looked at
the problem carefully, came up with approach XYZ and reduced the time
to market by 10%."
     
That's my two cents worth.
     
------------------------------
     
Date: 6 May 88 10:25:46 GMT
From: milano!titan!janssen@cs.utexas.edu  (Bill Janssen)
Subject: Boswell
     
In article <3058@teklds.TEK.COM>, michaelo@teklds.TEK.COM (Michael O'Hair) write
s:
> ... After a project is
> completed, successful or not, the "project history" [should be] collated
> and presented to management, who will, hopefully, read it and learn
> what went right and what went wrong.
     
Seems to me that that attitude right there, of hopeful historians presenting
something to "management", who may or may not read it, is its own problem.
This will only work if you have management *pulling* for those results,
asking for the data, eager to see how they can do better.
     
------------------------------
     
Date: 28 Apr 88 12:12:52 GMT
From: mcvax!ukc!stl!stc!datlog!dlhpedg!cl@uunet.uu.net  (Charles Lambert)
Subject: Boswell and the Project Chronicles
     
In article <40335UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes on the
subject "Who builds tools?":
>Put in a broader perspective, maybe every project ought to have someone
>who, while not being good at the techniques the final code will contain,
>IS good with tools and tool building.
     
In a similar vein,  I believe that every project should have a "Boswell"
(cf. Dr Johnson) whose job is to look over the team's collective shoulder
and write down all those nuggets of expertise,  revelation and folklore
that eventually (in our imperfect profession) make the original team
indispensable.  Boswell's brief would be either
     
i.      to write the project documentation, or
ii.     to note everything that needs to go into the project documentation
        so that the team leader can chase the responsible parties.
     
That documentation would include clear instructions for the use of the
Toolsmith's creations AND an explanation of the underlying procedure, so
that new recruits will not be crippled when the special tools fail.
     
The measure of his or her success would be the ease with which new members
could be brought up to speed and the lack of involvement by the development
team after handing over to maintenance.
     
Boswell's effort would have a profound effect on the integrity of the code,
the consistency of the design and,  hence,  the cost of maintenance because
the philosophy and foibles of the implementation - things which are usually
either opaque or invisible to late recruits and maintainers - would be
recorded.
     
------------------------------
     
Date: 2 May 88 13:30:07 GMT
From: uh2%psuvm.BITNET@jade.berkeley.edu.user%host.BITNET@CUNYVM.CUNY.EDU  (Lee
Sailer)
Subject: Boswell and the Project Chronicles
     
In article <758@dlhpedg.co.uk>, cl@datlog.co.uk (Charles Lambert) says:
>
>In a similar vein,  I believe that every project should have a "Boswell"
>(cf. Dr Johnson) whose job is to look over the team's collective shoulder
>and write down all those nuggets of expertise,  revelation and folklore
>that eventually (in our imperfect profession) make the original team
>indispensable.  Boswell's brief would be either
>
     
Brooks's "surgical team" approach provides for this, but not in the pattern
you suggest.  It is the Chief Programmer's job to oversee the documentation.
A librarian/secretary/editor is on the team to relieve the workload.
     
The "Boswell"  (nice term) is the assstant to the Chief Programmer, and
very few official duties, except to hang around the Chief Programmer,
look over his or her shoulder, know everything the chief programmer knows,
and be ready to step in at a moments notice if the CP gets hit by a truck.
     
Brooks proposes that inexperienced but promising programmers would fill
this role, sort of like a medical resident assisting in surgery.
     
------------------------------
     
Date: 3 May 88 14:18:05 GMT
From: fad@think.com  (franklin a davis)
Subject: Boswell and the Project Chronicles
     
In article <41127UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes:
>
>Brooks's "surgical team" approach provides for this, but not in the pattern
>you suggest.  It is the Chief Programmer's job to oversee the documentation.
>A librarian/secretary/editor is on the team to relieve the workload.
>
>The "Boswell"  (nice term) is the assstant to the Chief Programmer, and
>very few official duties, except to hang around the Chief Programmer,
>look over his or her shoulder, know everything the chief programmer knows,
>and be ready to step in at a moments notice if the CP gets hit by a truck.
>
     
There have been several recent references to Brooks' CP model.  The
main problem I see with it is that, realistically, few projects are
lucky enough to find a "super-programmer" with the skills and talent
to fill the role.
     
------------------------------
     
Date: 5 May 88 12:29:08 GMT
From: mnetor!spectrix!yunexus!geac!daveb@uunet.uu.net  (David Collier-Brown)
Subject: Boswell and the Project Chronicles
     
In article <20437@think.UUCP> fad@balder.think.com.UUCP (franklin a davis) write
s:
>There have been several recent references to Brooks' CP model.  The
>main problem I see with it is that, realistically, few projects are
>lucky enough to find a "super-programmer" with the skills and talent
>to fill the role.
     
   Well, its more like they lack the ability to attract them.  I
know at least four, all from my year at a single university.  Mind
you, at the time I met them, they weren't super yet, and therefore
had little trouble getting jobs.  Now that they're smarter than
their bosses, things get harder...
     
------------------------------
     
Date: 7 May 88 13:20:04 GMT
From: uh2%psuvm.BITNET@jade.berkeley.edu.user%host.BITNET@CUNYVM.CUNY.EDU  (Lee
Sailer)
Subject: Boswell and the Project Chronicles
     
Brooks's Chief Programmer model does *not* require that the CP be a super-
programmer.  Only that there be someone who is responsible for being
intimately familiar with every line of code that goes in the final
product.  To make this possible, the CP must be relieved of being
familiar with code used for testing, tools, editing, and so on.
     
Note that lots of super programmers would make poor CP's, because of
a lack of ``people skills''.  They might make great Boswells, and
learn to be CP's someday.  They probably would be best at the tool maker
job, where the ability to throw together something new in a flash is
important.  This leads to interesting organizational problems--the
tool smith, who ``supports'' the CP is likely to be more important than
the CP, and could quite reasonable expect to be paid more.
     
------------------------------
     
Date: 27 Apr 88 17:36:26 GMT
From: linus!philabs!ttidca!hollombe@husc6.harvard.edu  (The Polymath)
Subject: Who builds tools?
     
In article <40335UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes:
+... One way to do that is to give
+every a surgeon a ToolSmith, who builds tools for the surgeon so that
+he doesn't have to build them hirself.
+
+... maybe every project ought to have someone
+who ...
+... IS good with tools and tool building.  ...
+... whose *specialty* is awk, emacs,
+shell, yacc, etc etc etc.
     
There's tools and tools.  My semi-official position right now is tool
builder for our QA department.  I build and maintain programs used to
stress test and regression test ATMs, among other things.  These have to
run in real time (simulating a person using the ATM) and are written
entirely in C.  My office mate is our group's nominal shell expert and
writes the scripts used to start up the ATMs and invoke my tools.
     
In previous jobs I've written test tools in FORTRAN for Space Shuttle
displays, also running in real time. (Hmmm ...  I seem to have done a lot
of this, now I think of it (-: ).
     
The Unix toolkit is a marvelous and useful thing, but restricting yourself
to it is much too narrow a definition of "tools".
     
------------------------------
     
Date: 29 Apr 88 05:52:12 GMT
From: tektronix!orca!stank@ucbvax.berkeley.edu  (Stan Kalinowski)
Subject: Who builds tools?
     
I have just finished a project where I was a toolsmith.  Looking back,
I must say that that creation of a tools team was probably one of the
best ideas I've seen in software engineering in a long time.  Let me
describe the problems that my engineering organization faced.
rent hardware platforms.
     
  o The engineers needed to make a transition from an 80286 to a 68020
    processor and another transition from Intel development equipment
    to Tektronix development equipment.
     
[ For those of you out there who are busy trying to deduce Tektronix'
  competitive position from the above info ... don't try.  I am only
  talking about the one group my team served.  There were others.       ]
     
There are a number of things that came out of my experience that I
think were good lessons.  I'll list them here for the benefit of anyone
thinking of creating a software tools organization (team).
     
  - When it comes to creating tools, buy or borrow as much as you can.
    Don't spend valuable time re-inventing the wheel.  Leverage the
    support that the tool suplier provides.  (This means choosing a
    suplier that offers good support, and delivers it.)  If you write
    the tools yourself, plan to spend a great deal of time supporting
    users.
     
  - Create a "charter" document for the tools team.  It is very
    important that responsibilities and objectives are clearly
    identified.  It is too easy to become a catch-all group, the group
    that does all the "odd" jobs.  Doing odd jobs is not necessarily
    bad, but a charter document helps point up the fact that a tools
    group, like any other group, has fixed resources and those
    resources are deployed against a priortized list of objectives.
    Addition of a new responsibility usually means adjustment of the
    tools group objectives or deliverable schedule.
     
  - Make the tools team responsibilities, objectives, priorities, and
    schedule well known.  This helps others to do their planning by
    clearly defining what resources (tools) will be available and when
    they will be available.  It also helps curb requests for tools
    that are far outside the capability of the tools team.  When an
    engineer thinks of a new tool to request he/she can prioritize
    it's importance against the existing tools plan.  In this way,
    requests for frivolous tools are nipped in the bud by the
    requestor, no feelings are hurt, and the requestor usually decides
    that it's not worth doing it on their own.  Good ideas generally
    pass this test and are then incorporated into a revised tools
    plan.  The tools plan generally evolves as the needs of the
    project evolve.  This guarantees that the tools team is always
    working towards delivering what's needed, when it's needed.
     
  - Define a set of standard operating procedures and then make sure
    everybody is told what they are.  This usually covers such things
    as:
     
     o What to do when hardware fails.
     
     o How to request new tools.
     
     o Where can new users find manuals and other documentation.
     
     o What is the process for reporting problems with tools.
     
     o Who are the "guru's" for things outside the tools team's
       area of responsibility.
     
  - Staff the tools team carefully!  A tools team is no place for
    substandard engineers.  The quality and support of tools impacts
    the productivity of the entire organization it supports.  If the
    tools get in the way, engineers and sometimes managers will begin
    to roll up their sleeves and take matters into their own hands.
    On a well managed project everyone already has a full schedule, if
    the engineers have to take up tools team slack, the schedule
    slips.  The team I was on had good balance, one engineer having
    previous experience with the product line and the tools used in
    the past, and another engineer that had exceptional interpersonal
    and communication skills and previous tools experience.  (You can
    tell by my spelling that I am the former. :-) )
     
  - Communicate, Communicate, COMMUNICATE.  If you don't adequately
    and promptly convey how-to information, installation status,
    bug-fix status, and new tools availability, you will spend most of
    the day answering questions and not make any progress on new tool
    development.  (Even though we bought or borrowed most of our tools
    we still needed to develop "glue" tools to make them all work
    harmoniously.)
     
  - Learn to be a lightning rod.  When something stops working, take
    the responsibility even if it's not your problem.  Don't fix
    blame, fix the problem!  Be the person to go to in a crisis.  A
    can-do attitude is definitly required for a successful tools team.
    If your management is not mature enough to recognize that even the
    best plans cannot anticipte all eventualities, they probably won't
    support the idea of a tools team either, so don't worry about how
    your record will look.  Don't try to hide the fact that something
    isn't working out.  Note: having a good plan is critical, be
    willing to accept the input of managers or anyone else.  Don't let
    pride get in the way of serving your client engineers well.  If
    everyone has input to your plan the likelyhood of screwing up is
    greatly reduced.
     
  - Don't wait for trouble, go out and look for it.  Cruise the debug
    areas looking for frustrated engineers, and then offer to help.
    Don't be shy about it.  People will often struggle with a problem
    much longer than necessary because they feel stupid when they
    can't make a tool do what they want.  People tend to think they're
    the only person in the world having trouble.  Usually this is not
    the case at all.  Searching out trouble is especially important
    after introducing a new tool.  Some people will understand your
    user interface style right off, some won't.  It's important to
    identify useability problems early and then correct them before
    too many people get discouraged.  Often this requires quick user
    interface or documentation changes.
     
Now, I'll answer the question that everyone asks: "Why would an
experienced product software engineer take a job in a lowly tools
group?".  [ I remember when my manager asked me if I would work on
tools, he asked me and then took a step back as if he expected me to
swing at him, I replied "Hmm, tools... O.K.  He was quite suprised.]
     
There are a number of reasons why I like working on tools, let me list
them.
     
  - The type of stress one encounters in a service organization (like
    a tools team) is different than that of a development
    organization.  Pressure on a product development engineer is low
    at the beginning of a project and then climbs gradually to a peak
    at the end of a project.  In contrast, the tools team experiences
    bursts of pressure during planning, implementation and the
    sustaining period.  The bursts of pressure are separated by
    relative calm.  I'm not saying one kind of pressure is better than
    the other, but the change is pleasant.
     
  - I was probably one of the most vocal complainers about our old
    development environment.  I figured if anyone knew what was needed
    it was me.  My experience with the old tools helped me avoid many
    pitfalls with the new tools.
     
  - I like to learn new things.  I tend to learn quickly on my own.  I
    was always one of the people to ask about the obscure features of
    our old development environment, why not turn that into an
    official responsibility?  I have always liked to help my fellow
    engineers.  Working on the tools team allowed me to actualy set
    aside time in my schedule to help people and learn new things.
     
  - Beware, future tools persons, anyone thinking that the tools team
    would be the best place from which to enforce their own opinions
    about design philosophy or any other aspect of software
    engineering is doomed to failure.  I can hear the gears turning
    out there.  "Gosh, if the do-hickey tool only works on MY style of
    C code, they'll have to code it my way!"  FORGET IT!  If you think
    like this you'll wind up alienating everybody and writing a lot of
    tools that nobody can use!  (They probably wouldn't use them even
    if they could.)
     
  - Working on the tools team has helped me to develop my
    interpersonal skills.  I think I've matured and I'm generally a
    better person for my efforts.  Of course this probably could have
    happened anywhere.
     
------------------------------
     
End of Soft-Eng Digest
******************************