Path: utzoo!mnetor!uunet!tektronix!orca!stank From: stank@orca.TEK.COM (Stan Kalinowski) Newsgroups: comp.software-eng Subject: Re: Who builds tools? Message-ID: <2539@orca.TEK.COM> Date: 29 Apr 88 05:52:12 GMT References: <321@uwslh.UUCP> <40335UH2@PSUVM> Reply-To: stank@orca.UUCP (Stan Kalinowski) Organization: Tektronix, Inc., Wilsonville, OR Lines: 170 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