Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!bellcore!duncan From: duncan@ctt.bellcore.com (Scott Duncan) Newsgroups: comp.software-eng Subject: Re: Personal growth and software engineering! Message-ID: <1991Apr8.122140.3727@bellcore.bellcore.com> Date: 8 Apr 91 12:21:40 GMT References: <1991Mar25.164133.29674@unislc.uucp> <549@tivoli.UUCP> Sender: usenet@bellcore.bellcore.com (Poster of News) Reply-To: duncan@ctt.bellcore.com (Scott Duncan) Organization: Computer Technology Transfer, Bellcore Lines: 124 In article <549@tivoli.UUCP> alan@tivoli.UUCP (Alan R. Weiss) writes: > >Bzzt. Wrong. The *first* step is identifying a problem in specific terms. Agreed and measurement can help do this. However, identifying a place where you think you want to change can direct early measurement effort toward some goal. Usually, a problem prompting people to look for a solution manifests itself as the need to reduce the cost of development, improve the quality of the output, etc. Measurement can make the terms in which that problem are ex- pressed more specific. >If there is not a problem, why bother? Agreed but individuals may feel like they are having no problems while the organizational output seems to have some. If individuals are not used to public visibility of their work, things may seem fine to them as they are getting "their work done" to their own satisfaction. If the standards of performance (day to day...I am not discussing merit reviews, etc.) are up to the individual professional alone, there can be tremendous variation in the direction in which folks are headed. (Perhaps any one of the directions is fine, but a hal dozen different ones makes for organizational chaos.) > Note that this can include a >desire to increase productivity and/or quality. But you better be specific. I'm not sure you are implying that you can't have both. But it sounds like it. From what I have heard many organizations report, you can have both (except, perhaps, in the most stringent quality situations). Most recently, I heard a speaker indicate that their best day for quality so far was also their most productive. (This was not in software, but in a delivery service con- text. Large software producers have reported that a focus on quality has led them to improved productivity. It is not clear that the reverse would be as true.) >Some people may not have a standard by which to compare themselves. Or it is their own personally developed one which is fine for their own sense of well-being, but have much less value in a larger context. >True, some people don't want to change. We have a term for that: >unemployed. In the '90's, we can be sure that change is constant ;-) Yes...people talk about this a great deal. I am not sure...other than the day the axe falls, that the sense of urgency is portrayed effectively enough so a large enough number of professionals (and their management) feel this. There has to be a better way to get started down the road toward improvement than simply to suddenly become unemployed. That simply says people missed the boat and that the situation went well beyond where they could do anything about the situation. We need to be able to tell that things are heading out of control at a point where something can be done about it -- and shown to people so they understand what to do. (Threats of job loss just get people looking for some more secure job. They do not get people to change very effectively.) >If the metrics are bogus, then fix them by including the workers >in the process. Hopefully, you try to avoid putting in "bogus" metrics in the first place by including workers in the process of instituting them in the first place. > In this case, "process" can mean calling a short >meeting, identifying dumb metrics, and coming up with meaningful ones. I suggest it will take longer than "a short meeting" to do this and get some useful measurement effort in place. Being too efficiency-minded at the outset is likely to get "bogus" measures or process to occur. One of the complaints heard most often about metrics efforts is that they take too much time. Too short a preparation period is likely to have just this effect because the ef- fort required to collect and analyze the results falls on the shoulders of those who need to be creating th system and may be ill-prepared to initiate a measurement program. Probably the value of a short meeting is, as you say, to "identify dumb metrics" and avoid them. Then encourage folks to propose useful ones, describe how they could be most painlessly collected and analyzed, and suggest changes they would like to see made in their development process. Arrange another meeting to have this information presented and see what convergence of views can be reached. If you can achieve agreement here, then setting folks to work on implementing some measures should go more smoothly. >But to discredit measurements because some are unreliable is to >throw the baby out with the bath water. Absolutely. On the other hand, to parade the idea of measurement around just because it seems "scientific" and "professional" will make a joke out of the effort fairly quickly. >If I were YOUR manager, I would have YOU measure yourself. And coupling that with the opportunity to improve oneself as you suggest would make the measurement effort more meaningful. However, as I pointed out in my previous posting, most measurement programs seem to get initiated from top-down at some large organizational level. It is rare that things are startewd from the bottom up since the reason for the program always seems to be a management desire for information/data and not individual improvement. (Management expects that the latter will happen as if by some "proferssional" magic.) >Clearly the absence of measurements relegates software creation to >the arts, rather than as an engineering and/or scientific discipline. Agreed. >No one is more aware than I of the role of people in the process. >But treating programmers like anything less than professionals is insulting. But I feel the definition of what lots of people think it means to be a "pro- fessional" includes _not_ being measured too specifically since it implies a lack of trust. I think we have to change the sense of what it means to be measured, targeting improvement rather than evaluation, as well as establish that "professionalism" means more public sharing of what's going on, i.e., more visibility, not because of lack of trust, but because of the necessity for growth through exchange of experience. >Alan R. Weiss TIVOLI Systems, Inc. >E-mail: alan@tivoli.com 6034 West Courtyard Drive, >E-mail: alan@whitney.tivoli.com Suite 210 >Voice : (512) 794-9070 Austin, Texas USA 78730 >Fax : (512) 794-0623 Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (908-699-3910 (w) 609-737-2945 (h))