rcd@ico.ISC.COM (Dick Dunn) (10/06/89)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes, among other things, that: > ...But engineers don't play; this is left > for hackers. We're here to engineer products on time, under budget, > and with as much quality as we can get within those two constraints. Actually, engineers *do* play; the ones who don't seem to be playing are playing at being engineers. But that's another posting. Here, I want to assert that the "on time, under budget" phrase is a red herring. (BTW, why not "ahead of time, on budget" or even getting both right and being "on time, on budget"? But that's another digression...) It's particularly sad to see "quality" a poor third to the other two. You can make any feasible software project come in on time by setting a long enough schedule, and of course you can bring it in under budget if you set aside enough money. That's why we've got a red herring--the numbers can be tweaked. Moreover, this is not just an idle observation... There are lots of "methodology mavens" on the loose these days. They'll sell you or teach you a way to improve the predictability of your software projects. An unfortunately large proportion of them do it by adding make- work to projects, in a particular way: They front-end load the project with paperwork, rituals, meetings, millstones, etc. What does this do? - It increases the total time/budget for the project, providing a way to hide needed time/money. If things start to get tight, the ritual gets short shrift; the effort gets shifted to real work. You get a safety buffer you don't have to justify. - It lets you hire (or assign) the people you're going to need in the later implementation phase early on...and it gives them some- thing to do (push paper) without getting in the way too much. (After this, they'll be GLAD to get to work!) This allows lazy management to deal with a flat staffing through the project. - It adds to the total time/money for the project, so that any error in estimation induced by true risk is reduced in apparent magnitude by the slopfactor. The next point may come as a radical surprise (or affront) to the academi- cians (and Adacademicians especially), but: It's not necessarily best to produce a schedule which you know you can meet at a very high confidence level! Sure, if you're aiming for a hard deadline or bidding a contract fixed-price, you need to hit pretty high confidence. But in many cases it makes more sense to set the schedule at the most probable completion time. That's the most useful for planning. For example, in the commercial world, aiming for a 90% confidence-of-completion time on a schedule might cause you to decide you can't meet the market window for a product--when in fact a more realistic confidence level in scheduling will tell you it's worth the chance. In any event, a single "schedule end date" or "cost" for a software project is carelessly simplistic; it's as bad as rating processor performance on a single number. You need to associate confidence levels with the values. But overall, Wolfe has it backward. You need to produce quality software that does what it's supposed to do. Then you need to do it predictably. But if the software doesn't work, it doesn't matter how quickly or cheaply it was done. -- +---------+ Dick Dunn rcd@ico.isc.com ico!rcd (303)449-2870 | In this | 4th annual MadHatterDay [10/6/89]: | style | A Thousand Points of Madness |__10/6___|
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/06/89)
From article <16168@vail.ICO.ISC.COM>, by rcd@ico.ISC.COM (Dick Dunn): >> ...But engineers don't play; this is left >> for hackers. We're here to engineer products on time, under budget, >> and with as much quality as we can get within those two constraints. > > why not "ahead of time, on budget" or even getting both right and being > "on time, on budget"? But that's another digression...) It's particularly > sad to see "quality" a poor third to the other two. If the product does not meet the minimal standards of acceptability, then it is not complete. "On time", etc., refers to the product being completed in accordance with the relevant quality requirements. Bill Wolfe, wtwolfe@hubcap.clemson.edu
itkin@mrspoc.Transact.COM (Steven M. List) (10/08/89)
rcd@ico.ISC.COM (Dick Dunn) writes: > ... stuff deleted ... >In any event, a single "schedule end date" or "cost" for a software project >is carelessly simplistic; it's as bad as rating processor performance on a >single number. You need to associate confidence levels with the values. >But overall, Wolfe has it backward. You need to produce quality software >that does what it's supposed to do. Then you need to do it predictably. >But if the software doesn't work, it doesn't matter how quickly or cheaply >it was done. >-- In reading what Dick said, I can only believe that he's never worked on a project for which someone ELSE was paying. Or a project for which the market window is critical to the continued survival of the company or the project or the product. He implies (probably unintentionally) that Mr. Wolf's approach is unrealistic and financially motivated. He says that his statements will come as a surprise to the Academicians. Dick's statements strike me as somewhat ivory tower. While those of us who consider ourselves professionals in the field of "software engineering" presumably ALWAYS strive for quality products, we can't just turn off our systems and refuse if someone comes along and says "we have a deadline". Rather, we have to make every effort to compromise and push and squeeze and produce the required product in the required timeframe and within the specified budget. This is REALITY. Now, I don't want Dick to misunderstand. I laud his goals. I too believe that our first goal SHOULD be quality software. Define quality. Unfortunately, too often, that translates to "as much functionality as can be gotten in that works reliably as we can fit within our constraints". Happily and sadly, we live in a commercial environment. As such, we are controlled, largely, by the need to earn dollars so we can continue to do what we enjoy doing. Having become a principal in a business within the last couple of years, I've had to learn this lesson even more painfully than before. No doubt, there will always be those who will take one side or the other. "Quality MUST come first, even at the risk of lost opportunity or lost business." "Meeting our deadlines and our budgets is paramount. If the product isn't up to standards, well, we'll adjust later or change our marketing." The truth is that living in the real world ALWAYS requires compromise. From what time you get up in the morning to what you eat for lunch to whether or not you include a feature in the software you are developing. To survive, you must adapt. Adaptation FREQUENTLY requires compromise. So, I guess, I believe that you have to fit all things together. The question I must always ask myself, when we start a project or task, is "How much can I get in that meets MY/OUR/OUR CUSTOMER'S standards of quality within the time and budget constraints set forth? Can we modify the constraints? Are we willing to adjust our standards?" Dick's statement that producing a schedule that meets a lower confidence factor would permit a favorable decision is frightening to me. This implies that it's okay to plan based on 80% or 70% or lower confidence. This implies that he is willing to proceed based on the assumption that HE CANNOT SUCCEED in meeting time or budget constraints. Dick - who's funding you? What happens when the date for which you had 70% confidence comes and goes? Who eats it? I would rather produce a realistic project plan up front, including specifying the compromises, than to produce a falsely optimistic plan with a qualifier ("this is only 70% certain") and have to scramble to adjust near the end. -- +----------------------------------------------------------------------------+ : Steven List @ Transact Software, Inc. :^>~ : : Chairman, Unify User Group of Northern California : : {apple,coherent,limbo,mips,pyramid,ubvax}!itkin@guinan.Transact.COM :
rcd@ico.ISC.COM (Dick Dunn) (10/11/89)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > >> ...We're here to engineer products on time, under budget, > >> and with as much quality as we can get within those two constraints. > > ...It's particularly > > sad to see "quality" a poor third to the other two. > If the product does not meet the minimal standards of acceptability, > then it is not complete. "On time", etc., refers to the product > being completed in accordance with the relevant quality requirements. "Quality" software is MUCH more than software which meets "the minimal standards of acceptability", thank you. A piece of software may be judged to have been "completed" on time and within budget if it meets its stated requirements within those constraints. The requirements are going to be objective criteria--such as tasks the software must perform, performance and size limits, etc. They MUST be objective criteria in the (very common) case where the requirements are part of the negotiated contract for the software project. It is entirely possible to construct software which meets all such require- ments, but which is poorly conceived or implemented. Examples abound. I know of no way to specify software requirements such as "must be able to survive the next five years of changes, to meet new needs, hacked in by bored second-string maintenance programmers..." But that's often what quality software needs. Sometimes software doesn't need high quality--sometimes the minimal hack that meets the short-term requirements is enough! The "lowest bidder" approach is OK sometimes, but not universally. Most software far outlives its originally estimated/intended life. It is more common to find our- selves with software under-engineered than over-engineered. My personal peeve here is that I spend far too much of my time reworking under-engin- eered hacks back into decent code that can survive. So I see an extreme focus on budget/schedule as needlessly increasing the amount of such work I have to do. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
rcd@ico.ISC.COM (Dick Dunn) (10/11/89)
itkin@mrspoc.Transact.COM (Steven M. List) writes: >...In reading what Dick said, I can only believe that he's never worked on > a project for which someone ELSE was paying. Or a project for which the > market window is critical to the continued survival of the company or the > project or the product... You are quite wrong on both counts. I have worked on both for many years; currently most of my work falls into projects paid for by customers. I think it's not that we are in any fundamental disagreement (we'll see) so much as that we're driving at different points. > Dick's statements strike me as somewhat ivory tower. While those of us > who consider ourselves professionals in the field of "software engineering" > presumably ALWAYS strive for quality products, we can't just turn off our > systems and refuse if someone comes along and says "we have a deadline". Understood completely. I'm NOT trying to put quality at the very top of the list, to the exclusion of schedule and budget...but I want to get schedule/budget off the top of the list. One of the things we have to consider in bidding a software project is that we want to set a reasonable cost which will allow us to produce a product of sufficient quality that the customer is not only happy with it in the short-term (meeting the immediate needs) but in the long term when it comes time to modify it. If it's our own product, we don't want to do a quick hack that will save us 10% on the first release and cost us 50% more in the second release when we have to repair the damage we did by hurrying. Sometimes, market pressures are extreme enough that it's the only way to hit close enough to the market window that there can BE a second release--but we need to avoid that. > "How much can I get in that meets MY/OUR/OUR CUSTOMER'S standards > of quality within the time and budget constraints set forth? Can > we modify the constraints? Are we willing to adjust our standards?" This is a good statement. The software MUST meet its requirements, but that's a separate issue. We MUST schedule enough time and money to do that. Then we try to schedule enough to produce a product of sufficient quality that we won't hate ourselves for it later on. > Dick's statement that producing a schedule that meets a lower confidence > factor would permit a favorable decision is frightening to me. This > implies that it's okay to plan based on 80% or 70% or lower confidence. Sure--why not? Wait, let me qualify that...There are circumstances where it's OK to work at that confidence level. Just remember that nothing is black and white here. Suppose we're talking about a product aimed at a particular market window. What's the accuracy of the end date on the market window? Probably 50% at best! (That is, the window is at least as likely as not to close AFTER the estimated end date.) Also, the window doesn't just slam shut...it means that the longer you delay, the smaller your market share. You have to work with the probabilities involved. If there's a 70% chance you can make the stated market window, you also need to know something like what your 90%-confidence completion date is, and whether that might come in acceptably close to the window that it will still give you a good product--enough to make some money even if not as much as you "should" make. There are literally SCORES of other factors to consider. The better the condition of the company, the more of a gamble you can afford to take. You may build the company's reputation in a new technology area; you may gain expertise you need as a side-effect of the project. You have to look at the type of contract you're going to work with, if it's contract work. You can bid base cost plus T&M at a lower confidence level than fixed-price, which in turn can be lower than fixed-price-with- penalty-for-late, which is different from fixed-price-with-bonus-for-early, etc. to endless detail. Sometimes you don't even bid because the terms your customer wants don't fit with the amount of risk (which translates into level of confidence for a plausible schedule) for the project. > This implies that he is willing to proceed based on the assumption that > HE CANNOT SUCCEED in meeting time or budget constraints... No, it implies that I might be willing to proceed even with the knowledge that the desired (ideal) outcome is less than certain. But it involves lots of other considerations, per above, if you're going to go ahead from a lower confidence value. >...Dick - who's > funding you?... Our customers. >...What happens when the date for which you had 70% > confidence comes and goes? Who eats it?... If the project is begun at a low confidence level, there will be aspects of the contract which anticipate that. If an estimate carries a low confi- dence, that's taken into account. >...I would rather produce a > realistic project plan up front, including specifying the compromises, > than to produce a falsely optimistic plan with a qualifier ("this is > only 70% certain") and have to scramble to adjust near the end. It depends on what the curve of confidence level vs schedule looks like. All such curves have a tail asymptotic to 100%. With some, the shape of the tail heading out past 75% or so is unpleasantly long...that tells you that the project is riskier than average, and you have to decide whether you can live with the risk. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (10/11/89)
From rcd@ico.ISC.COM (Dick Dunn): >> >> ...We're here to engineer products on time, under budget, >> >> and with as much quality as we can get within those two constraints. >> > ...It's particularly >> > sad to see "quality" a poor third to the other two. >> If the product does not meet the minimal standards of acceptability, >> then it is not complete. "On time", etc., refers to the product >> being completed in accordance with the relevant quality requirements. > % It is entirely possible to construct software which meets all such require- % ments, but which is poorly conceived or implemented. Examples abound. I % know of no way to specify software requirements such as "must be able to % survive the next five years of changes, to meet new needs, hacked in by % bored second-string maintenance programmers..." But that's often what % quality software needs. [...] My personal peeve here is that I spend % far too much of my time reworking under-engineered hacks back into % decent code that can survive. So I see an extreme focus on % budget/schedule as needlessly increasing the amount of such work I % have to do. This depends upon whether the product is implemented by hackers or by professionals. A professional will meet cost and schedule constraints by using CASE tools, advanced programming languages, and so on, using overtime as the last resort. A professional knows that developing modular, readable software not only helps make the software maintainable, but also reduces the probability that the product will be delayed due to errors and reduces the time that will be required to correct errors if they are discovered, thereby enhancing the probability of meeting scheduling constraints. Dick's particular environment is one in which operating system software is being developed in C, a double whammy as far as a well-established tradition of hacking is concerned. In such an environment, great efforts must be taken on the part of management to ensure the existence of a proper software engineering orientation. Bill Wolfe, wtwolfe@hubcap.clemson.edu
hallett@positron.uucp (Jeff Hallett x5163 ) (10/12/89)
In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >It is entirely possible to construct software which meets all such require- >ments, but which is poorly conceived or implemented. Examples abound. I Therefore it is time someone addressed the issue of how to quantitatively specify nebulous terms like "user friendly", "maintainable", "extendible", etc. In a requirements document, these terms have no meaning aside from the warm and fuzzy connotations. To quote Star Trek: The Next Generation ("Samaritan Snare"), the space moron stated : "We look for things: things to make us go." Sure, but quantify it. How does one specify a requirement for "user friendliness" or "well-written"? -- Jeffrey A. Hallett, PET Software Engineering GE Medical Systems, W641, PO Box 414, Milwaukee, WI 53201 (414) 548-5163 : EMAIL - hallett@gemed.ge.com "Your logic was impeccable Captain. We are in grave danger."
rsd@sei.cmu.edu (Richard S D'Ippolito) (10/12/89)
In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >It is entirely possible to construct software which meets all such require- >ments, but which is poorly conceived or implemented. Examples abound. I >know of no way to specify software requirements such as "must be able to >survive the next five years of changes, to meet new needs, hacked in by >bored second-string maintenance programmers..." But that's often what >quality software needs. There are ways to do it. One can generally anticipate the areas of change, especially in large systems where there is a long history of changes. For example, suppose you require software for a flight trainer used to simulate operation at several airports, i.e., the characteristics of the airports are used to drive the simulated display and the cockpit instruments. Can't it be required that the capability of changing the airport(s) be designed in? It is possible for the contractor to include in his bid the effort (read "cost") to do this. Suppose you are building a C3I system based on a large number of electronically received messages which have to be translated and validated before being stored in a database. Should you not require the contractor at proposal time to tell you the cost of adding or deleting new messages, some of which are of the same types and some of which are probable new types (if known)? There are many other examples I could give, as these types of systems have been around long enough for us to have a good idea of the nature of the expected changes. It merely requires the program office to request the cost of the anticipated changes in the proposals. As you can see, the contractor (read "software engineer") is going to need some concrete idea of what he's going to build in order to be responsive, but, hey, isn't that true of other engineers? Watch for it -- happening soon to a contractor near you! Rich -- It is not the possible that determines what to hope for -- it is hope that determines what is possible. Richard J. Oman rsd@sei.cmu.edu -----------------------------------------------------------------------------
phil@attctc.Dallas.TX.US (Phil Meyer) (10/12/89)
In article <6742@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From rcd@ico.ISC.COM (Dick Dunn): > > This depends upon whether the product is implemented by hackers > or by professionals. Haven't we had the hacker vs. professional wars before? I am reminded of the fortune "A poor workman blames his tools". It is also a poor workman who must blame tools for other's inferior workmanship. This next statement suggests that you are not professional if you do not use CASE tools. Pretty silly. Most developers are still eyeing CASE. > A professional will meet cost and schedule > constraints by using CASE tools, advanced programming languages, > and so on, using overtime as the last resort. This last line is the killer. If you don't work your butt off, you don't work for me! If the job needs doing, you stay 'till it's done. What is this? Bankers ethics in the computer center? Forget it! > Dick's particular environment is one in which operating system > software is being developed in C, a double whammy as far as a > well-established tradition of hacking is concerned. In such an > environment, great efforts must be taken on the part of management > to ensure the existence of a proper software engineering orientation. This statement applies to ANY environment. It may be true that sloppy programmers working in a CASE environment can produce better code than without CASE, but steps must still be taken to insure that guys like you who won't stay past quitting time, don't just throw stuff together! This isn't really a flame, I was just suprised to see stuff like this in a news group where I'm certain that most participants dream of the day when they can work 'regular' hours.
linda@rtech.rtech.com (Linda Mundy) (10/12/89)
In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: [...some discussion of "on time, under budget" vs. "quality", deleted...] >"Quality" software is MUCH more than software which meets "the minimal >standards of acceptability", thank you. > [...more good stuff deleted...] > >It is entirely possible to construct software which meets all such require- >ments, but which is poorly conceived or implemented. Examples abound. I >know of no way to specify software requirements such as "must be able to >survive the next five years of changes, to meet new needs, hacked in by ^^^^^^^^^^^^ >bored second-string maintenance programmers..." But that's often what ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >quality software needs. > Dick, I really agreed with the main points of your article, making the above remark come as a surprise. Not picking you in particular, but this is such a common attitude towards maintenance programmers, I thought it might be appropriate as a topic of discussion in its own right. So I ask you: -- do you think maintenance work is easier than development work? always? sometimes? never? does your answer change for large systems vs. small systems? -- do you think that maintenance programming belongs lower on the "pecking order" than development programming? -- do you think that such presumptions are likely to help people work together more effectively? -- do you think that software engineers should do a stint at maintenance, or do you think that maintenance is a place to put the (perceived to be) less talented? -- do you think maintenance should be a separate function, or that developers should be responsible for maintaining their own code (as much as possible)? -- do you think that there are different skill sets for maintenance vs. development? if so, is one skill set "better" than another? You can probably tell, you hit one of my hot buttons. I personally think that any new, just-out-of-school programmer should do maintenance work for awhile (assuming, of course, that the company already has a product!) It will introduce them to the product they will be working on, in a context where they can both learn and have something to show for it. It will introduce them to the prevailing coding style. It will introduce them to the many pitfalls and pratfalls that lead to bugs, thus hopefully teaching them how to avoid same. It may introduce them to the real-world effects of software bugs on customers, thus improving their attitudes towards software quality. etc., etc. But the most important point: don't diminish people because of their relative positions. It can't do any good -- in fact, it is exactly such attitudes that lead to "bored, second-string" employees -- wherever they happen to be in the organizational structure. As I said before, this is not meant as a flame, and judging by your other statements, I doubt that we are in basic disagreement. Of course, I could be wrong! (but only about the previous statement...;-)) >-- >Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 > ...No DOS. UNIX. -- "Who are you to tell me to question authority?" Linda Mundy {ucbvax,decvax}!mtxinu!rtech!linda
rcd@ico.ISC.COM (Dick Dunn) (10/12/89)
I was gritching about quality being given short shrift, and had pointed out that software can be constructed which meets all objective requirements, yet is of poor quality. > This depends upon whether the product is implemented by hackers > or by professionals... Hey, groovy...we'll just get our customers to add a clause to the contract to require that "All software shall be implemented by professionals. Hackers shall not be employed..." and nobody will have to worry about poor quality software any more, right? Of course good people will produce better software than bad people. That is true, but irrelevant to the point I was trying to make--which is that the relative emphasis on quality will influence the result. A good programmer, under extreme time/budget pressure, will likely be able to produce better-quality software than a dullard working at leisure who codes with a chainsaw . But the professional won't do as good a job as if there were more external interest in quality and less extreme time/money pressure. >...A professional will meet cost and schedule > constraints by using CASE tools, advanced programming languages, > and so on... No. A professional will use the tools suitable for the job (perhaps creating them if appropriate). A professional will focus on the job of constructing good software, and will leave the buzzword-oriented programming to the acolytes of strongly-hyped languages. (apologies to Andrew Koenig) And what's this about advanced programming languages? Wolfe has, in other postings, been an outspoken advocate of Ada, which is certainly *not* advanced. In fact, the difficulty of making Ada catch up to current technology has been a hot topic over in comp.lang.ada. > Dick's particular environment is one in which operating system > software is being developed in C, a double whammy as far as a > well-established tradition of hacking is concerned... There is operating system software developed in C at Interactive Systems. That's not what I'm doing, although that is irrelevant. C is well suited to the task. (Most of the OS work is, for example, better done in C than in C++. But you have to understand what "most of the work" is about, and that's another topic.) The "well-established tradition of hacking" is an empty insult, a manifes- tation of Wolfe's inability to mount any substantive objection. C works. UNIX works. They've lasted well, and survived incredible amounts of modifi- cation and adaptation. All the cheap insults you can dream up won't change that. We'll trade taunts with you for a while; then we'll let you go back to *talking* about software while we *produce* software. Don't get me wrong--C is *not* The One True Way. (That's religion, which is anathema:-) C is *a* way to get things done, and done both well and expeditiously. There are other languages and tools--some of them more appropriate to their problem domains than C could be. > In such an > environment, great efforts must be taken on the part of management > to ensure the existence of a proper software engineering orientation. Not at all. You just get good people who know what they're doing, and make room for them to do their jobs. Good management does not direct; it assists. The people I work with are not the people who produce the nasty code I was complaining about in my earlier posting. In fact, some of the nastiest code was produced as a result of blind, dogmatic application of so-called software engineering principles. It's gotten them into binds. We have to help them out, help clean up the messes, and get the software headed back in a reasonable direction. We do it in C (since that's what all of them are using), without dogma and buzzwords. Sometimes we have to tell them that getting back to quality software is going to cost a little more and take a little longer than the "shortest path" to meeting the immediate requirements. When we can make a good case for it, they're likely to go for it--because they've seen how we work and they appreciate the long- term benefits. We budget and plan for quality work; we don't "lowball" contracts. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
sps@ico.ISC.COM (Steve Shapland) (10/12/89)
In article <3807@rtech.rtech.com> linda@rtech.UUCP (Linda Mundy) writes: >In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >>I know of no way to specify software requirements such as "must be able to >>survive the next five years of changes, to meet new needs, hacked in by > ^^^^^^^^^^^^ >>bored second-string maintenance programmers..." ... > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ..... I personally think that >any new, just-out-of-school programmer should do maintenance work for awhile >(assuming, of course, that the company already has a product!) It will >introduce them to the product they will be working on, in a context where they >can both learn and have something to show for it. ... I agree with the policy of assigning rookie programmers to maintenance tasks. The learning experience is wonderful. Most companies I've worked for tend to follow this policy, and I believe that this is what leads to Dick's view of maintenance programmers. 1) "hacked" - Being rookies, they are still learning the product, style, and problems of real-world (large complex systems) programming. Their code tends to lack the polish of craftsmanship. 2) "bored" - Being youthful, they still possess the dream of setting the world on fire. "Enough of this working on last year's code, I want to design the next major system." They are being forced to walk when they want to run. 3) "second-string" Of course they're second-string. They still have to prove themselves to management; and until they do, the more senior people of the team continue to carry the ball. There is yet another reason for assigning junior programmers to maintenance tasks. Don't forget that maintence represents ~80% of the life cycle costs of a software product. By assigning programmers from the low end of the pay scale, these costs may be reduced. All of the above sounds brutal, but the benefits, to both the programmers and the companies who pay their salaries, are very significant. My pet peeve regarding quality software is programmers who insist on the status quo, without considering improvements in their toolkits and development processes. These programmers are still producing code with last year's methods and setting poor examples for the junior programmers who have to fix that code next year. Quality development is an continual spiral. As you introduce quality improvements, the quality of the each succeeding product generation improves. The inverse is also true. If you do not introduce quality improvements in the development process, the quality of the future products continues to deteriorate. The real problem for management is the intial cost of getting into the right spiral. Once on the proper path, quality methods becomes second nature. Steve Shapland Interactive Systems Corp.
ted@nmsu.edu (Ted Dunning) (10/12/89)
In article <3807@rtech.rtech.com> linda@rtech.rtech.com (Linda Mundy) writes: In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: ... I personally think that any new, just-out-of-school programmer should do maintenance work for awhile (assuming, of course, that the company already has a product!) ... why wait until then? one of the most important things that any course in software engineering should have students do is work on a large system. for that matter, so should _all_ but the most basic courses. if you have compiler class, make them work on a real compiler, in a course on semantics, make them work with the semantics of a real language. ... But the most important point: don't diminish people because of their relative positions. It can't do any good -- in fact, it is exactly such attitudes that lead to "bored, second-string" employees -- wherever they happen to be in the organizational structure. ... i am not sure that dick was trying to diminish people asmuch as he was just observing that the programmers who do maintenance and typically _are_ bored, typically _are_ second-string. -- ted@nmsu.edu Dem Dichter war so wohl daheime In Schildas teurem Eichenhain! Dort wob ich meine zarten Reime Aus Veilchenduft und Mondenschein
rcd@ico.ISC.COM (Dick Dunn) (10/13/89)
linda@rtech.rtech.com (Linda Mundy) writes about my comment that one hard- to-pin-down aspect of new-code quality might be: > >..."must be able to > >survive the next five years of changes, to meet new needs, hacked in by > ^^^^^^^^^^^^ > >bored second-string maintenance programmers..." ... > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ She says: > Dick, I really agreed with the main points of your article, making the above > remark come as a surprise. Not picking you in particular, but this is > such a common attitude towards maintenance programmers, I thought it might be > appropriate as a topic of discussion in its own right... I agree with Linda's sentiments. Now, to be clear about why I said what I did: It IS a common attitude toward maintenance programmers. It's an unfortunate, stupid, misdirected attitude. Not only do I NOT agree with it; it makes me angry. BUT it's there, and has to be reckoned with. In other words, I pointed out that quality software needs to survive being hacked over by bad maintenance programmers not because maintenance SHOULD be done that way, but because it WILL be done that way, in all likelihood. You have to make the software a little hardier than it should need to be in order to survive what it will be put through. Maybe I should also have been careful with the wording so that it would have been clear that I meant (second-string) (maintenance programmers), as opposed to (second-string maintenance) programmers. > -- do you think maintenance work is easier than development work? Sometimes it is - routine changes may be very easy to make. Sometimes it's not - the effects of an apparently small change may run across the grain and affect a large part of the code, requiring exceptional perspicacity to keep from screwing up the code. > ...does your answer change for large > systems vs. small systems? My initial reaction is that it doesn't. It changes depending on the structure of the system. The more interconnected a system is, the harder some changes are. > -- do you think that maintenance programming belongs lower on the > "pecking order" than development programming? As a rule, no. However, it is usually PLACED lower in the pecking order. Sometimes, maintenance work can be used effectively for training--in this sense, you spend time learning an existing body of code, understanding how things are done, seeing problems, etc., before you go create new code. It works if it's done carefully. > -- do you think that software engineers should do a stint at > maintenance, or do you think that maintenance is a place to > put the (perceived to be) less talented? > -- do you think maintenance should be a separate function, or that > developers should be responsible for maintaining their own > code (as much as possible)? All software engineers should spend time on maintenance. Since maintenance, in the general sense which includes modification, porting, and the like, is MOST of what software folk spend their time doing, having people work only on new code puts them a bit out of touch with reality. One approach is to assign people to a software project "cradle to grave." That is, if you write it you maintain it. You get to take on a new project when the work load for the old one drops below some threshold. This has an interesting incentive--if you want to work on new stuff, you may be more careful getting things right so you don't have to do a lot of maintenance time. The approach also has a handful of flaws, but it's worth exploring it in some environments. > -- do you think that there are different skill sets for maintenance > vs. development? if so, is one skill set "better" than > another? We need to get development and maintenance to equal prestige. There are people who LIKE to work on existing code, shaping it to new needs. There are others who are better at cutting from whole cloth; they have trouble reworking other people's code. We should be able to accommodate these different abilities. > You can probably tell, you hit one of my hot buttons... Yes, and I did so unintentionally; it seems that we're mostly in agreement. But it's just as well. It's a topic that needs to be dragged out into the open periodically. It has been realized for perhaps two decades that maintenance tasks are perceived as "inferior" in many organizations. It has also been realized that this leads to poor maintenance. But we per- petuate those damaging stereotypes. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
barnes@Xylogics.COM (Jim Barnes) (10/13/89)
In article <16202@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: > >One approach is to assign people to a software project "cradle to grave." >That is, if you write it you maintain it. You get to take on a new project >when the work load for the old one drops below some threshold. This has >an interesting incentive--if you want to work on new stuff, you may be more >careful getting things right so you don't have to do a lot of maintenance >time. The approach also has a handful of flaws, but it's worth exploring >it in some environments. One disadvantage to this approach is that it will encourage turnover of personnel. "I'm tired of just doing maintenance and since I can't get assigned to some new development, I'll just go somewhere where I CAN work on something new." Then you have to hire new programmers to do maintenance anyway. >We need to get development and maintenance to equal prestige. There are >people who LIKE to work on existing code, shaping it to new needs. I agree, but it seems that it is very hard to find these people. Maybe the truly good maintenance programmers do not change jobs very often. ---- Jim Barnes (barnes@Xylogics.COM)
richard@pantor.UUCP (Richard Sargent) (10/13/89)
> From: linda@rtech.rtech.com (Linda Mundy) > Message-ID: <3807@rtech.rtech.com> > Date: 11 Oct 89 22:49:07 GMT ... > Not picking you in particular, but this is > such a common attitude towards maintenance programmers, I thought it might be > appropriate as a topic of discussion in its own right. > Most companies I have encountered have the attitude that it takes a particularly *skilled* person to be a *successful* maintenance programmer. Think about it for a few moments: when you come along, pick up some else's code, have to find and fix a bug in the shortest possible time frame (since it is delaying your customers!), and so on. Good maint.programmers are worth their weight in gold (well, maybe silver :-) to companies which have a significant investment in existing products. In an ideal world, it would be nice if we developers didn't create programs with any bugs, so maint.programmers would only have to deal with enhancement requests, but it just ain't that way now, and won't be for quite some time to come. :-( Richard Sargent Internet: richard@pantor.UUCP Systems Analyst UUCP: uunet!pantor!richard
rcd@ico.ISC.COM (Dick Dunn) (10/14/89)
rsd@sei.cmu.edu (Richard S D'Ippolito) writes: > ... rcd@ico.ISC.COM (Dick Dunn) writes: [about the hard-to-pin-down adaptability needs] > >..."must be able to > >survive the next five years of changes, to meet new needs,... > There are ways to do it. One can generally anticipate the areas of change, > especially in large systems where there is a long history of changes. Yes, you can anticipate some of the needs. But there's a whole continuum of possible changes. Some future needs are so explicit that you can actually put provisions in your requirements that the code be "ready" for the changes--in effect, what you do is specify and design for a feature; you just don't implement it. Next along the spectrum is the type of change Richard is talking about-- You may not be able to pin down the exact change you'll need, but you know the general area and direction. The type of change I'm interested in is all the way down at the other end of the spectrum...the changes which will eventually come about because someone comes up with a need and says, "Wait a minute! What about the xyzzy program? Doesn't it do a lot of this stuff? Could we adapt it to do what we need?" It may be an adaptation of the program to add a capability, or you might clone the program and transmogrify the clone. I don't have many clues of how to characterize or measure the adaptability of code to such unanticipated needs. I'm not even sure it makes sense to try to measure it. But I do know that it's common to look at recycling code this way...and I know that "quality code" will allow it to happen. It's hard to make analogies with other areas of engineering about this sort of change, because software is so much more mutable. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
bander@cs.odu.edu (Jim Bander) (10/14/89)
In article <1189@mrsvr.UUCP> hallett@gemed.ge.com (Jeffrey A. Hallett (414) 548-5163) writes: > >Therefore it is time someone addressed the issue of how to >quantitatively specify nebulous terms like "user friendly", >"maintainable", "extendible", etc. In a requirements document, these >terms have no meaning aside from the warm and fuzzy connotations. To >quote Star Trek: The Next Generation ("Samaritan Snare"), the space >moron stated : "We look for things: things to make us go." Sure, but >quantify it. > >How does one specify a requirement for "user friendliness" or >"well-written"? I'm not sure anyone will ever QUANTIFY user-friendliness in a way that would help me design better systems. But Paul Heckel (formerly of PARC) SPECIFIED the requirement 30 useful ways in _The Elements of Friendly Software Design_ (Warner Books, 1984). His point is that software designers who think like engineers are doomed to fail, as was Thomas Edison when he tried to make movies. Engineers develop the medium; writers and artists use it to communicate effectively! -- ----------------------------------------------------------------------------- Jim Bander, Tidewater Consultants, Inc., Virginia Beach, VA Internet: bander@cs.odu.edu Ma Bell: (804) 497-8951 USnail: 160 Newtown Rd. #415 Va. Beach, VA 23462 "It's not the things we don't know that get us into trouble; it's the things we do know that ain't so." --Will Rogers ----------------------------------------------------------------------------- Disclaimer: All my mistaken opinions are my own.
linda@rtech.rtech.com (Linda Mundy) (10/17/89)
In article <16198@vail.ICO.ISC.COM> sps@ico.ISC.COM (Steve Shapland) writes: >In article <3807@rtech.rtech.com> linda@rtech.UUCP (Linda Mundy) writes: >>In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >>>I know of no way to specify software requirements such as "must be able to >>>survive the next five years of changes, to meet new needs, hacked in by >> ^^^^^^^^^^^^ >>>bored second-string maintenance programmers..." ... >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> ..... I personally think that >>any new, just-out-of-school programmer should do maintenance work for awhile >>(assuming, of course, that the company already has a product!) It will >>introduce them to the product they will be working on, in a context where they >>can both learn and have something to show for it. ... > >I agree with the policy of assigning rookie programmers to maintenance >tasks. The learning experience is wonderful. Most companies I've >worked for tend to follow this policy, and I believe that this is >what leads to Dick's view of maintenance programmers. > Well a few people have pointed out the apparent contradiction of (a) wanting maintenance to be respected and (b) assigning rookies to do it. First, I did not say nor mean to imply that *only* rookies should be doing maintenance, just that *all* rookies should do some. None of this "this guy's too smart to 'waste' his time doing maintenance". In my experience, even smart programmers benefit a *lot* by exposure to the problems that occur when software gets out there in the real world -- they see first-hand that software may be used in ways that are not foreseen; they experience the agony of trying to debug something which has bad error handling/lack of tracing facilities/ etc... Hopefully, they learn from this how to code defensively. [...Steve's other comments deleted for brevity...] > >Steve Shapland >Interactive Systems Corp. -- "Who are you to tell me to question authority?" Linda Mundy {ucbvax,decvax}!mtxinu!rtech!linda
linda@rtech.rtech.com (Linda Mundy) (10/17/89)
In article <16202@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >linda@rtech.rtech.com (Linda Mundy) writes about my comment that one hard- >to-pin-down aspect of new-code quality might be: >> >..."must be able to >> >survive the next five years of changes, to meet new needs, hacked in by >> ^^^^^^^^^^^^ >> >bored second-string maintenance programmers..." ... >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >She says: >> Dick, I really agreed with the main points of your article, making the above >> remark come as a surprise. Not picking you in particular, but this is >> such a common attitude towards maintenance programmers, I thought it might be >> appropriate as a topic of discussion in its own right... > >I agree with Linda's sentiments. Now, to be clear about why I said what I >did: It IS a common attitude toward maintenance programmers. It's an >unfortunate, stupid, misdirected attitude. Not only do I NOT agree with >it; it makes me angry. BUT it's there, and has to be reckoned with. In >other words, I pointed out that quality software needs to survive being >hacked over by bad maintenance programmers not because maintenance SHOULD >be done that way, but because it WILL be done that way, in all likelihood. >You have to make the software a little hardier than it should need to be >in order to survive what it will be put through. > >Maybe I should also have been careful with the wording so that it would >have been clear that I meant (second-string) (maintenance programmers), as >opposed to (second-string maintenance) programmers. > Well your main point remains valid, i.e. that one needs to think about future maintenance/enhancement when coding something. The phrase quoted above just jumped out at me -- like a red flag in front of a bull -- and demanded comment... >-- >Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 > ...No DOS. UNIX. -- "Who are you to tell me to question authority?" Linda Mundy {ucbvax,decvax}!mtxinu!rtech!linda
jrj1047@ultb.UUCP (J.R. Jarrett) (10/18/89)
titled "Software Maintenance is a Solution, not a Problem" in the Jan '89 issue of System Development. He stated that the goal of maintenance should be to maximize efficiency rather than minimize cost, and to do that, the best people should be attracted to and placed in maintenance positions. It doesn't always happen that way. I work for a software maintenance group, and the new hires are the ones that get put in there; the experienced people move on to more "interesting" ventures. It's nice to say "Put the best people in", but until it happens in industry, it's no more than lip service.
madd@world.std.com (jim frost) (10/19/89)
In article <3829@rtech.rtech.com> linda@rtech.UUCP (Linda Mundy) writes: >In article <16202@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >>You have to make the software a little hardier than it should need to be >>in order to survive what it will be put through. [...] >Well your main point remains valid, i.e. that one needs to think about >future maintenance/enhancement when coding something. Yes; the technique I've used is to error-check arguments everywhere that performance isn't ABSOLUTELY necessary, even in distributed code. This costs some performance but improves the initial quality and future maintainability. During development it catches early programming errors, saving debug time. Sometimes it saves a LOT of debug time. During maintenance it provides known points of failure which can be used in tracking reported bugs and drops the likelihood that low-quality programmers will use functions incorrectly. jim frost software tool & die madd@std.com
cweir@richsun.UUCP (Charles Weir) (10/19/89)
In article <1189@mrsvr.UUCP> hallett@gemed.ge.com (Jeffrey A. Hallett (414) 548-5163) writes: >In article <16187@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >>It is entirely possible to construct software which meets all such require- >>ments, but which is poorly conceived or implemented. Examples abound. I > >Therefore it is time someone addressed the issue of how to >quantitatively specify nebulous terms like "user friendly", >"maintainable", "extendible", etc. In a requirements document, these >terms have no meaning aside from the warm and fuzzy connotations. [...] >How does one specify a requirement for "user friendliness" or >"well-written"? > Tom Gilb, in his book "Principles of Engineering Management", devotes a lot of attention to this problem. He recommends a system of metrication for all of these things. It's not impossible - just important: The following is taken from a the chapter "Attributes Specification". , and is only section out of some twenty from an example specification: MAINTENANCE COST: SCALE=minutes/line of non-commentary source code maintained/year TEST=Logged maintenace minutes for system/estimated code lines WORST( New code, created by new process) = 0.2 min/LOC/year WORST( Old code, existing today) = 0.5 min/LOC/year PLAN(new code)= 0.1M/L/Y (based on Fagan's inspection experience) PLAN( old)= 0.3 M/L/Y NOW(estimated overall for Company today) = 0.5 M/L/Y REFERENCE= now estimate is based on 5000 programs, avg. 5000 loc/program, 70% of 250 programmers in maintenance Note: The targets (he calls them metrics) are measurable. There are best and worst values according to what actually happens: that answers the question "Well how can I predict until I know exactly what I'm doing?". And the figures will provide a reference for estimating success and failure. I'ld be interested to know if anyone else out there is used to doing this kind of analysis. I find it valuable. Charles Weir Own Opinion. Might be company's too.
cweir@richsun.UUCP (Charles Weir) (10/20/89)
In article <1989Oct18.201225.3330@world.std.com> madd@world.UUCP (jim frost) writes: >>>You have to make the software a little hardier than it should need to be >>>in order to survive what it will be put through. >[...] >>Well your main point remains valid, i.e. that one needs to think about >>future maintenance/enhancement when coding something. > >Yes; the technique I've used is to error-check arguments everywhere >that performance isn't ABSOLUTELY necessary, even in distributed code. > >This costs some performance If performance is important, then make it an option (Compile option in C, I don't know in other languages): #if defined (CHECK)... [check all parameters] #endif That isn't quite as convenient as leaving the checks in permanently, but it allows one to use the technique in virtually ALL code. It's funny how little public domain code does this... -- Charles Weir, Rich Inc, Franklin Park, IL 60131 Email: cweir@richsun.uucp uunet!richsun!cweir