UH2@PSUVM.BITNET (Lee Sailer) (04/25/88)
In the Mysthical Man-Month, Brooks describes the surgical-team model for programming projects, where one person is responsible for all of the code. Of course, to make this possible, we have to offload as much work as possible from the "surgeon". 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. 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 the traditional Unix environment, a project should contain at least one person whose *specialty* is awk, emacs, shell, yacc, etc etc etc.
EGNILGES@pucc.Princeton.EDU (Ed Nilges) (04/27/88)
In article <40335UH2@PSUVM>, UH2@PSUVM.BITNET (Lee Sailer) writes: >In the Mysthical Man-Month, Brooks describes the surgical-team model >for programming projects, where one person is responsible for all of the >code. Of course, to make this possible, we have to offload as much >work as possible from the "surgeon". 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. In many projects, however, the lead person should be the tool smith. We find in applications that the end user is often the best programmer of her own application. For example, I found working in Seattle on a ship stability program that an Ocean Engineer with access to good tools could do most of the application himself quite effectively; I concentrated on the more systems oriented aspect of the work, viz., the screen manager. But programmers are themselves the end user of things like compilers and debuggers. They know what they need...just as Ocean Engineers know what the master of a vessel needs (actually, the master herself probably knows even better than the engineer, but that's a matter of degree and a division of labor within ocean engineering that I am not qualified to address). Anyway, the fact that programmers know their tools explains why senior people want to work on tools...it's the same phenomenon as the end-user who wants to use Lotus 123 to do her own models. It's more fun, and a better product is often the result. Yes, the user is paying for real work, not toolcrafting; but if the real work is done several orders of magnitude faster and more accurately because the team members have good tools, the person paying the bill has no reason to complain.
beckenba@cit-vax.Caltech.Edu (Joe Beckenbach) (04/27/88)
In article <40335UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: > [...] >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 the traditional Unix environment, >a project should contain at least one person whose *specialty* is awk, emacs, >shell, yacc, etc etc etc. While I was working under a professor of Computer Science here on a long-term project [ie 20 years so far] there was one grad student who held essentially that position informally. I'm starting to learn about the power of sed and other unixtools, mainly because I've seen some of the stuff he cooked up. The piece of work which, when I first encountered it and said "It's magic!", blew my mind was a little one-line shell command in a makefile. It invoked sed on the makefile itself, used sed to locate all the pascal include dependencies on the vax, appended those to the makefile, cleaned up after itself, and quit. Back then, the concept of makefiles was keen stuff to me, green as I was [am]. He also did a lot of other support stuff for the rest of the design teams in this project, in addition to his own contributions outside of the tool realm. When I grow up into a unix wizard, I want to do stuff JUST LIKE THAT. :-) :-) -- Joe Beckenbach CS BS ?? -- I'D RATHER BE ORBITING
hollombe@ttidca.TTI.COM (The Polymath) (04/28/88)
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".
--
The Polymath (aka: Jerry Hollombe, hollombe@TTI.COM) Illegitimati Nil
Citicorp(+)TTI Carborundum
3100 Ocean Park Blvd. (213) 452-9191, x2483
Santa Monica, CA 90405 {csun|philabs|psivax|trwrb}!ttidca!hollombestank@orca.TEK.COM (Stan Kalinowski) (04/29/88)
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.
o We needed to build a large system (215,000 lines of C code) in less
than a year. (design, implement, test, and validate < 1yr)
o We needed to coordinate/integrate the coding effort of about 50
software engineers across 4 teams (to achieve the above schedule).
o The code had to support two different 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.
--
US Mail: Stan Kalinowski, Tektronix, Inc.
Information Display Group, Graphics Workstations Division
PO Box 1000, MS 61-028, Wilsonville OR 97070 Phone:(503)-685-2458
uucp: {ucbvax,decvax,ihnp4,allegra,uw-beaver}!tektronix!orca!stankrbl@nitrex.UUCP ( Dr. Robin Lake ) (05/09/88)
In article <2539@orca.TEK.COM> stank@orca.UUCP (Stan Kalinowski) writes: > >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. > ... excellent rules of thumb and guidelines omitted for brevity ... I got bitten by the "tools" bug a long time ago (some code first done in 1973!) when UNIX was first generally available outside of Bell Labs. Since then, I've taught and enforced the tools concepts through two graduate programs I ran and also seen its value in industrial-strength projects the last 6 years. In addition to the fine suggestions in the above article, an important aspect of software-engineering-with-tools is to incorporate the tools concepts into the DESIGN process. If you have a good structured design discipline and your designers KNOW the tools that are on the shelf, the design results in modules that are ALREADY CODED AND TESTED!! A few pieces of glue here and there and a new module or two --- but if your tool-kit is robust, there is probably a module there that only needs a few lines changed in order to meet the new module's specs. The primary benefit of this approach is that a PROTOTYPE system can be shown to the user very quickly. "Is this what you asked for and what you wanted?" Cuts down on the "moving target" project objective in a major way. How did we do it --- simply --- just looked at all I/O in the UNIX way: a stream of bytes. Built "orthogonal" tools that did "every" operation possible on byte streams. Ditto higher structures -- words, lines, .... Yes, things do get more abstract within some modules, but the designer, and programmer see just an ASCII stream of bytes and can debug on this basis. To date, we have about 200 tool modules, the longest being about 5 pages of C code. When the modules are piped together to create the system, the system does run slowly. But once again, the prototype is up really fast, the project produces what the user wants, and --- egad --- sometimes the user accepts the "slow" fast prototype as a final product! ("If this works now, why waste any more time on speeding it up? We can buy a faster machine for the cost of a man-week of programming effort.") I did an article on a product developed using the design approach, using it for hardware/software design decisions, in IEEE Trans. Biomed Engineering, October 1982. "A High Speed Data Acquisition Subsystem" Summary: Tools work! Tools work far better if incorporated into the design process!! -- Rob Lake BP America Research and Development decvax!mandrill!nitrex!rbl mandrill.CWRU.EDU!nitrex!rbl