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!hollombe
stank@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!stank
rbl@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