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
******************************