bradn@tekig4.TEK.COM (Bradford Needham) (07/11/87)
In article <2365@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes: >Well, there is a third class [of programmers who write poorly-commented code]. >Some of us are actually not permitted to "do it right." >Out in the "real world," as they called it when I was still a student, >we have things called schedules and deadlines. While I agree that the real world exerts strong pressures to do things "the wrong way", and while I sympathize with every programmer that suffers under an inflexible, counterproductive organization, I don't agree that these pressures justify producing poorly-documented code. It is the engineer's responsibility to give his manager his best guess at technical "reality": how long things are going to take; how risky a certain feature or method is; what tradeoffs exist between time-to-market, product features, and product quality. Without this input, the manager is going to make unrealistic decisions. I agree that there has to be compromise between programming heaven (where there is plenty of time to thoroughly design, document, build, and test) and sales heaven (where products appear the moment a customer asks for them). Achieving a good compromise (a good-quality product in a timely manner) is the mark of a good engineer. Brad Needham bradn@tekig4.TEK.COM
garys@bunker.UUCP (Gary M. Samuelson) (07/13/87)
In article <1656@tekig4.TEK.COM> bradn@tekig4.UUCP (Bradford Needham) writes: >In article <2365@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes: >>Well, there is a third class [of programmers who write poorly-commented code]. >>Some of us are actually not permitted to "do it right." >>Out in the "real world," as they called it when I was still a student, >>we have things called schedules and deadlines. >While I agree that the real world exerts strong pressures to do things >"the wrong way", and while I sympathize with every programmer that suffers >under an inflexible, counterproductive organization, I don't agree that >these pressures justify producing poorly-documented code. I am not trying to justify it, just explain it. Doing it right in spite of the pressures shows up in your annual review as negative. >It is the engineer's responsibility to give his manager his best guess at >technical "reality"... Well, first, the manager has to ask for that input, and then, the manager has to accept the engineer's assessment as valid, and then, the manager has to convince the next manager(s) up that the end date dictated by Marketing can't be met. >I agree that there has to be compromise between programming heaven (where there >is plenty of time to thoroughly design, document, build, and test) and >sales heaven (where products appear the moment a customer asks for them). >Achieving a good compromise (a good-quality product in a timely manner) >is the mark of a good engineer. I am not sure that the two are mutually exclusive. If the marketing department were adept at their job, they would be able to anticipate what the customer is going to need in time for the engineering department to design, build, and test it (I left out "document," because I consider writing documentation to be an integral part of each of the other activities mentioned -- e.g., the result of designing is a design document -- but that's a nit). And if the engineering department were adept at their job, they would have, among other things, a set of "building block" software from which they could build most of any new product. Only the parts which were really new (and there isn't that much new in any given new product) would require new design. Gary K2 el 8 8
rha@bunker.UUCP (The Minister of Myrth) (07/13/87)
In article <1656@tekig4.TEK.COM> bradn@tekig4.UUCP (Bradford Needham) writes: >It is the engineer's responsibility to give his manager his best guess at >technical "reality": how long things are going to take; how risky a certain >feature or method is; what tradeoffs exist between time-to-market, product >features, and product quality. Without this input, the manager is going to >make unrealistic decisions. >I agree that there has to be compromise between programming heaven (where there >is plenty of time to thoroughly design, document, build, and test) and >sales heaven (where products appear the moment a customer asks for them). >Achieving a good compromise (a good-quality product in a timely manner) >is the mark of a good engineer. Brad, I think that Gary, and others here at Bunker, exemplify what you are talking about. In other words, estimates which emanate from the Engineer include all facets of the development process (including documentation). In addition, the Engineering Supervisors typically support these estimates. What Gary is talking about is that, by the time the various big cheeses get their hands on the estimates and label them as "unacceptable" (although NO functionality is disposable), what invariably gets killed, in the name of "expedience" (we know this isn't true), is documentation. Therefore, I suggest to you that a "good engineer" may have all the right intentions and informs all the right people, while it is only the "influential engineer" who actually get to the ear drum of the decision makers. -- {yale!,decvax!,philabs!}bunker!rha Bob Averack Bunker Ramo, an Olivetti Company Two Enterprise Drive - Shelton, Connecticut 06484
gwl@rruxa.UUCP (George W. Leach) (07/15/87)
In article <2396@bunker.UUCP>, garys@bunker.UUCP writes: > In article <1656@tekig4.TEK.COM> bradn@tekig4.UUCP (Bradford Needham) writes: > >In article <2365@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes: > >>Well, there is a third class [of programmers who write poorly-commented code]. > >>Some of us are actually not permitted to "do it right." > >>Out in the "real world," as they called it when I was still a student, > >>we have things called schedules and deadlines. > > >While I agree that the real world exerts strong pressures to do things > >"the wrong way", and while I sympathize with every programmer that suffers > >under an inflexible, counterproductive organization, I don't agree that > >these pressures justify producing poorly-documented code. > > I am not trying to justify it, just explain it. Doing it right in > spite of the pressures shows up in your annual review as negative. Personal and professional pride dictate doing it right (or trying to) anyway! > > >It is the engineer's responsibility to give his manager his best guess at > >technical "reality"... > > Well, first, the manager has to ask for that input, and then, the manager > has to accept the engineer's assessment as valid, and then, the manager > has to convince the next manager(s) up that the end date dictated by Marketing > can't be met. > > >I agree that there has to be compromise between programming heaven (where there > >is plenty of time to thoroughly design, document, build, and test) and > >sales heaven (where products appear the moment a customer asks for them). > >Achieving a good compromise (a good-quality product in a timely manner) > >is the mark of a good engineer. > > I am not sure that the two are mutually exclusive. If the marketing > department were adept at their job, they would be able to anticipate > what the customer is going to need in time for the engineering department > to design, build, and test it (I left out "document," because I consider > writing documentation to be an integral part of each of the other > activities mentioned -- e.g., the result of designing is a design document -- > but that's a nit). And if the engineering department were adept at their > job, they would have, among other things, a set of "building block" > software from which they could build most of any new product. Only > the parts which were really new (and there isn't that much new in any > given new product) would require new design. > > Gary Samuelson Everyone in a company must be committed to doing it right! Not just the programmer, but management, the customers, everyone!!!! It is too easy to promise the customer the world, with little preliminary work to adequately define just what it is that the customer wants. Then as time marches on and it become obvious that dates will be slipped, the first thing that everyone drops are the quality arrangements that were set up. For example, design and code reviews were the first thing to go! Then features are dropped, then corners are cut!!!! The problem is in short term thinking on the part of too many people. How often have you seen people make decisions and promises that just are not reasonable. Then they are promoted before the SH*T hits the fan!!!! Ever see the "6 Phases of a Project" sign? The very last one is "Praise and Honors for the Non Participants". Oh, how true!!! If when a project team is put together, it was made clear that all members of the team would be there for the duration of the project, then you would have a great deal more interest in doing it right. Too often short sighted politics gets in the way. Manager X wants to use this project for the visability it will provide to get him/her a promotion. If all works right, promise all sorts of things and you will get that promotion before the promises must be realized! Don't laugh, it happens far too frequently. But why not? Afterall, isn't this the way that our government leaders operate as well????? Next election. George W. Leach Bell Communications Research New Jersey Institute of Technology 444 Hoes Lane 4A-1129 Computer & Information Sciences Dept. Piscataway, New Jersey 08854 Newark, New Jersey 07102 (201) 699-8639 UUCP: ..!bellcore!{indra | yogi | njitcis}!reggie ARPA: reggie%njit-eies.MAILNET@MIT-MULTICS.ARPA From there to here, from here to there, funny things are everywhere Dr. Seuss "One fish two fish red fish blue fish"
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/16/87)
Another common problem is that companies attempt to provide what the customer THINKS he wants, rather than what the customer REALLY wants. Satisfying the latter need should be the goal of a rational company, but it requires effort to determine what is really needed. I tend to give my business to companies that I perceive taking the latter approach, and I suspect enough other people do also that it would make good business sense for any company with limited clientele. Those selling to the "mass market" cannot of course work directly with their customers, even at the dealer level, so this approach may not make sense for companies in such a position.