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