X-NEWS: spcvxb alt.folklore.computers: 25019 Relay-Version: VMS News - V6.0-3 14/03/90 VAX/VMS V5.5; site spcvxb.spc.edu Path: spcvxb.spc.edu!rutgers!ub!zaphod.mps.ohio-state.edu!mips!apple!apple!netcomsv!mork!rowe Newsgroups: comp.edu,alt.folklore.computers Subject: What's a Programmer? Message-ID: <81nlcrc.rowe@netcom.com> From: rowe@netcom.com (Rick Rowe) Date: 21 Jun 92 15:27:45 GMT Distribution: usa Organization: Netcom - Online Communication Services (408 241-9760 guest) Lines: 173 Xref: spcvxb comp.edu:2636 alt.folklore.computers:25019 The following paper was written in an attempt to clarify problem areas and propose solutions to a "real life" situation. It should be taken lightly and looked at curiously. Today Software Engineering Principles are a major part of all Computer Science Degree Programs, but industry is slow to change and adapt to these new ideas. Especially when the change will require dollars to be invested "up front". The answer to the problem presented is quite simple, but trying to communicate that solution to older and more "set in their ways" managers can be a frustrating experience. :-( Enjoy! - Rick Rowe PS.This wasn't large enough to setup for ftp, but is large enough to apologize. However, it should be educational and that seems to be the purpose of these newsgroups. :-) Regards, Rick E-mail: rowe@netcom.com ---------------------------------------------------------------------------- What is a Programmer? From a Hardware Manager's Perspective. BY RICK ROWE Why do some programmers look different, act different, work different, and play different? Obviously there are no simple answers, but where does one start in the search for a level of understanding. First, one should clearly understand the definition of different. Second, one should try to comprehend those differences in relation to one's own attitude toward the workplace. Lastly, one should determine the consequences of those differences and evaluate courses of action to reduce the perceived impact at the workplace. To start on our quest to understand a programmer, we need to ask ourselves why it is necessary to begin the quest in the first place. The quest seems to be necessary since programmers can be hard to control and sometimes difficult to understand. "Trying to manage programmers is like trying to herd cats"(1). But, why is this? Well, let's first begin as planned and define "different". Being "different" is acting in a way apart from the norm. "The norm" is how the working majority act in the workplace. To help clarify this point, a Widget Test Organization can be used as an example. A system is designed and built which is used to test a widget. During the building of the Widget Test System, many design engineers (hardware and software) were required. The system was designed and implemented requiring many hardware devices and many thousands of lines of software. Now the system is in use. Most of the hardware designers are in a troubleshooting mode with some occasional new hardware design required. The software designers are also in troubleshooting mode with some occasional new software required to deal with new requirements. Here is where the definition of "different" can be established. For the Widget Test System hardware engineer, the majority of design work requires evaluating system schematics, understanding hardware components, understanding the electrical characteristics of the equipment, then getting out the hammer and nail to begin building. For the Widget Test System software engineer, the design work requires an understanding of the current software, learning the requirements needed by the new software, then sitting back in a chair and closing one's eyes. No, the software engineer is not tired from the days effort. The software engineer is visualizing the current software and how the new requirements can be satisfied by adding new software or by modifying the current software. Here is our first major difference. Now one may argue that the visualization is also required by the hardware engineer. This is true. But the difference is with the available tools. The hardware engineer has many tools like schematics, component specs sheets, test equipment, and a creative brain which are all used to develop and troubleshoot the design. The software designer has a hardcopy of the current code, a debug monitor, and a creative brain. Looking at the code hardcopy is much different than looking at a hardware schematic. The programmer must constantly rely on visualizing the design. Visualizing implies using the forces of creativity to get the job done. Wow! What a scary thought. The Test Department must rely on an individual's creativity to get a job done. This does not imply the software engineer is more creative than the hardware engineer, it does imply that the software engineer must rely on this creativity as a tool to do the software job. How about troubleshooting. The hardware engineer gets out a scope, a voltage meter, or perhaps a logic analyzer to begin troubleshooting. The hardware engineer takes measurements, evaluates readings, then forms a hypothesis as to the reason the problem occurred. The software engineer finds a chair next to a terminal, logs on to the computer, then sits back in the chair with eyes closed. What?!? No, the programmer is not trying to deal with the stress of the day by taking a quick cat nap. The programmer is attempting to visualize the current software design, how it interacts with the system, and what possible condition would cause the problem. For a manager trying to run the Test Organization, this can be a very frustrating experience indeed. With the hardware efforts, the manager can go out and touch, feel, and see how a troubleshooting or design effort is going. With the software, the manager walks around the terminal area and finds a bunch of strange looking creatures with their eyes closed. Of course, using an example where the programmer's eyes are closed is over simplification. It could be that the manager finds a group of programmers laughing, talking, and drawing strange looking pictures of what a four-dimensional object might look like. Well, the first reaction of the hard working manager is frustration, a feeling of lack of control, then anger becomes the dominant emotion. Now the definition of "different" has been established. In an effort to simplify the definition, one could conclude that the hardware and software engineers have vastly different tools in which to do their jobs. The use of these tools cultivates vastly different types of engineers. Depending on the background of the manager, there is a tendency to relate more with either the software or hardware engineers. This is not bad, it is just human nature. This leads into the second topic. An organization manager is usually selected from a particular organization (Hardware or Software). The selected manager is one who has proven to be an outstanding performer in a particular specialty. Since it is human nature to relate past experiences to learning, dealing with, and making important decisions, one can conclude that any behavior not familiar to the organizational manager will be considered different. In the case where the chain of organizational command is predominantly hardware, the programmer can be perceived to be one strange puppy. In the Widget Test Organization, the manager realizes that software is the life blood of the test hardware. So, the manager continues to try and understand what the software engineers are doing. This leads to the final topic in the quest for understanding. It is clear that there are differences between hardware and software engineers. It is also clear what "differences" implies as a definition. But, how can the organizational manager deal with this situation. The stubborn manager will continue to seek software visibility; and in doing so, will continue to be frustrated. A possible solution is to develop tools which are similar to the hardware engineer's tools. For most large software programs, test equipment will not help. There is a need to employ software development techniques like code walk-throughs, structure charts, flow charts, and block diagrams showing the software picture. In the case where there are thousands of lines of code already, it may cost the organization more time up front to get jobs done. But, the documentation remains for the next programmer or troubleshooting effort. There are many techniques used throughout the Software Development Industry which can be used by the programmer to help expedite the software visualization process. Using diagrams like structure charts or flow charts should help. These diagrams can compare to the hardware engineer's use of hardware schematics. If one extrapolates a bit, there may eventually be a need for Quality Assurance controlled drawings of software diagrams. But coming back down to earth for a second, these diagrams can help inform the organizational manager. Like the old saying goes, "A picture is worth a thousand words". (Especially when the words are in a foreign language). In summary, what is a programmer? A programmer is an engineer who must translate a book into a movie. Where the book relates to the lines of code, the executing software is the movie. Using limited tools, the programmer relies on creativity to get the job done. Now one may make the quick conclusion that the stranger the programmer, the more creative the programmer will be. Then the more creative the programmer, the better the programmer will be. Assumptions and generalizations are always dangerous. But false images are just as dangerous. The organization manager must realize that the organization will consist of many different types of talent. All of which have positive and negative aspects. To deal with this, the organizational manager must create an environment where communication is the number one priority. From schedules to code walk-thoughs, a balance must be formed. So how does a manager manage programmers? "The same way you train a tarantula, you don't. You learn how they react to stimuli, then apply the stimuli to get the job done. The alternative is rather messy. (You step on it.)" (2) References: (1) - A quote from an unknown author. (2) - A quote from an unknown author. Article Copyright 1992 by Rick Rowe The article may be freely redistributed as long as the author's name and this notice are retained. ---------------------------------------------------------------------------- -- =========================================================================== Rick Rowe - The C Programmers Network Newsletter+_ int x=10,y=20; | Editor Internet: rowe@netcom.com +_ x=x^y; y=y^x; x=x^y; | On a clear day you can C forever! +_ /* getting dizzy? */ |