karl@grebyn.com (Karl A. Nyberg) (05/27/91)
From Government Computer News, May 13, 1991, p. 63. The theory that Ada programming will get chaper as the Defense Department cashes in on the language's potential for reuse apparently has proved true for at least one Army system. Lt. Gen Jerome Hilmes, director of information systems for command, control, communications and computers, said Army programmers were able to design a 900,000-line demobilization system in 30 days for about $500,000. The quick programming turnaround was possible because about 800,000 lines of the Ada code were borrowed from previously designed systems, he said. The Army will use the new system as it deactivates more than 200,000 reservists called up to support the Persian Gulf war. The system, which automates the Army's standard discharge for for the first time, runs on AT&T Co. 3B2 minicomputers at seven locations. Hilmes said the system will reduce by a factor of two the time it takes to send a reservist back to civilian life. It was designed as part of the Army's continuing Installation Support Module program. Under ISM, the Army has standardized about eight servicewide functions performed at Army bases worldwide. So far, ISM officials "overall are getting about 56 percent reuse of the code they generate", he said. Hilmes spoke at a recent Armed Forces Communications and Electronics Association budget symposium in Arlington, VA.
chuck@brain.UUCP (Chuck Shotton) (05/28/91)
In article <9105271627.AA29654@grebyn.com>, karl@grebyn.com (Karl A. Nyberg) writes: > Lt. Gen Jerome Hilmes, director of information systems for command, control, > communications and computers, said Army programmers were able to design a > 900,000-line demobilization system in 30 days for about $500,000. The quick > programming turnaround was possible because about 800,000 lines of the Ada > code were borrowed from previously designed systems, he said. > This sounds like a simple enhancement job, not "new" development. 90% code reuse is more like 10% enhancement and maintenance. ----------------------------------------------------------------------- Chuck Shotton Internet: cshotton@girch1.med.uth.tmc.edu "Your silly quote here." UUCP: ...!buster!brain!chuck
jls@netcom.COM (Jim Showalter) (05/30/91)
chuck@brain.UUCP (Chuck Shotton) writes: >In article <9105271627.AA29654@grebyn.com>, karl@grebyn.com (Karl A. Nyberg) writes: >> Lt. Gen Jerome Hilmes, director of information systems for command, control, >> communications and computers, said Army programmers were able to design a >> 900,000-line demobilization system in 30 days for about $500,000. The quick >> programming turnaround was possible because about 800,000 lines of the Ada >> code were borrowed from previously designed systems, he said. >> >This sounds like a simple enhancement job, not "new" development. 90% code >reuse is more like 10% enhancement and maintenance. But this is precisely the direction we SHOULD be trying to head when we develop software! I can't think of a very strong business case for NOT reusing 800KSLOC whenever it is possible to do so, can you? Were that MORE projects achieved 90% code reuse, particularly if my taxes are paying for them. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
chuck@brain.UUCP (Chuck Shotton) (05/31/91)
In article <1991May30.004737.24473@netcom.COM>, jls@netcom.COM (Jim Showalter) writes: > >This sounds like a simple enhancement job, not "new" development. 90% code > >reuse is more like 10% enhancement and maintenance. > > But this is precisely the direction we SHOULD be trying to head when we > develop software! I can't think of a very strong business case for NOT > reusing 800KSLOC whenever it is possible to do so, can you? Were that > MORE projects achieved 90% code reuse, particularly if my taxes are > paying for them. > I don't disagree one bit. What I hate to see is another contractor horn-blowing what was ultimately a rehashing of existing code. It was certainly NOT a properly engineered system that drew on an established repository of reusable code. It is misleading to the customer and the industry at large to portray such development efforts as true reuse. I am NOT demeaning the achievement. Let's just call a spade a spade. Maybe "rapid tailoring" or "rapid reengineering" is a more suitable term for this type of approach. ----------------------------------------------------------------------- Chuck Shotton Internet: cshotton@girch1.med.uth.tmc.edu
jls@netcom.COM (Jim Showalter) (06/01/91)
>I don't disagree one bit. What I hate to see is another contractor horn-blowing >what was ultimately a rehashing of existing code. It was certainly NOT a >properly engineered system that drew on an established repository of reusable >code. It is misleading to the customer and the industry at large to portray >such development efforts as true reuse. I am NOT demeaning the achievement. >Let's just call a spade a spade. Maybe "rapid tailoring" or "rapid reengineering" >is a more suitable term for this type of approach. Chuck, why do I get the idea that we basically agree on a fundamental set of core principles, but keep getting wound around the axle because of semantics? You say tomayto, I say tomahto... (I'm not flaming--it is just an observation I've made.) Perhaps in this case the disagreement is simply due to my belief that the use of code more than once constitutes reuse BY DEFINITION, in contrast with some other notion you (I THINK) refer to as "true reuse". I guess the problem I have is I don't know what true reuse is, or how it differs from reusing (as opposed to rewriting from scratch) 800KSLOC of code on the project described at the beginning of this thread. I'm reminded, in fact, of a paper a friend of mine gave on reuse (he got his PhD in the subject) in which his opening words were "I'm not sure what reuse means". He went on to explain that it was a lot like the paradox of AI: every time someone achieves something in the AI domain, people respond by saying "Oh, well, THAT'S not AI, that's just <some other term>". And yet, progress keeps getting MADE in the AI field. Is reuse going to be a victim of the same phenomenon? My personal view of reuse is that it happens all the time, it happens in great amounts, and we all think there is a terrible problem with achieving reuse because we refuse to recognize it when it is staring us in the face because we were expecting something else, something more remarkable and harder to grasp. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
jcallen@Encore.COM (Jerry Callen) (06/04/91)
> [In several articles, Jim Showalter and Chuck Shotton debate whether > a recent Ada success should be called "enhancement and maintenance" > or "reuse."] I don't suppose anyone associated with the project is reading this news group, are they? Don't be shy! :-) I find it quite easy to believe that some 800K SLOC of Ada could be "reused" as is; I have a LOT of packages that I reuse all the time, and I can believe that a large system might be, say, 80% existing utilities (database management, windowing package, etc.) and 20% glue. On the other hand, I can also picture "enhancing" a large portion of not necessarily directly reusable code, making many changes in many places. Ada makes THAT relatively easy, too. SO - unless someone on the project can comment, let's admit that we're all guessing, shall we? :-) -- Jerry Callen jcallen@encore.com
hoysch@ucselx.sdsu.edu ( Hoysch) (06/05/91)
I believe it is possible to have 80% reuse and not just be a rehash. A sister project to the one I am working on released the first version of their project that had about the same % of reuse. The project (SMB, mentioned in AdaIC recent issue and in Ada strategies (the one from the December time frame). is more than rehash or maintanence because 3 subsystems from 3 other projects were extracted (w/ some modifications of course) and with a little new code to come up with the new product. Furthermore, the project that I am currently working on has (only a approximation) between 50 and 60% reuse, not counting C code that was converted (and often redesigned for) to Ada (often not too much savings). Dan "hoysch" Heuschele
jbg@sei.cmu.edu (John Goodenough) (06/05/91)
In article Re: Reserve Demobilization System Built Around Reused Ada Code of 30 May 91 18:30:53 GMT chuck@brain.UUCP writes: > code. It is misleading to the customer and the industry at large to portray > such development efforts as true reuse. I am NOT demeaning the achievement. > Let's just call a spade a spade. Maybe "rapid tailoring" or "rapid reengineering" > is a more suitable term for this type of approach. It is my impression that the figures quoted for high levels of software reuse and productivity in Japan are often based on just this kind of "rapid tailoring" or "rapid reengineering". I remember a paper some years ago concerned with generating process control software by a Japanese company in which they reported high levels of software reuse because they were tailoring their standard software to each customer's needs. Should we call it reuse when the end user is different, and otherwise call it enhancement? Depends on what techno-political games you want to play... John B. Goodenough Goodenough@sei.cmu.edu Software Engineering Institute 412-268-6391
jls@netcom.COM (Jim Showalter) (06/11/91)
>Should we call it reuse >when the end user is different, and otherwise call it enhancement? Depends >on >what techno-political games you want to play... My definition of reuse is quite simple: any time you didn't have to write a line of code, you reused it. This may not be the definition of reuse people envision when they use the term "reuse", but in the end all that truly matters is the COST--a line saved is a line earned. If you treat the entire software development process like a black box, then from the outside of the box it matters little why the box is more efficient than other software development boxes--all that truly matters is that it IS more efficient. If the box is more efficient because of "mere" software enhancement instead of "pure" reuse, so be it. It degenerates (like so many things) into an argument over semantics. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
pcg@aber.ac.uk (Piercarlo Grandi) (06/15/91)
On 11 Jun 91 06:27:03 GMT, jls@netcom.COM (Jim Showalter) said: (somebody)> Should we call it reuse when the end user is different, and (somebody)> otherwise call it enhancement? Depends on what (somebody)> techno-political games you want to play... jls> My definition of reuse is quite simple: any time you didn't have to jls> write a line of code, you reused it. This may not be the definition jls> of reuse people envision when they use the term "reuse", but in the jls> end all that truly matters is the COST--a line saved is a line jls> earned. But this does not capture what people "really" mean by reuse. Surely then using a DBMS, OS, math library, is "reuse" then, by your definition. IMNHO "reuse" is so poorly defined, because everybody (but me of course) does not understand sw development, that any discussion like "using X means more reuse" is pointless. For example the use of 4GLs, DBMSes, X windows, and math/GKS/stats/... libraries to me it is all reuse. Reuse is much more prevalent than people think, thanks to old fashioned concepts like servers (process based reuse) and libraries (module based reuse). Usually, I suspect, reuse is meant to be applied to the narrow case where one does custom sw development, which is no longer the case in most commercial installation; nearly everybody nowadays is using DBMSes and enjoying the benefits of not reimplementing from scratch data management programs. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
jls@netcom.COM (Jim Showalter) (06/15/91)
pcg@aber.ac.uk (Piercarlo Grandi) writes: >jls> My definition of reuse is quite simple: any time you didn't have to >jls> write a line of code, you reused it. This may not be the definition >jls> of reuse people envision when they use the term "reuse", but in the >jls> end all that truly matters is the COST--a line saved is a line >jls> earned. >But this does not capture what people "really" mean by reuse. Surely >then using a DBMS, OS, math library, is "reuse" then, by your >definition. Indeed! And what other term SHOULD we apply to using a DBMS instead of writing our own? See, that's what's so ironic about reuse--like AI, as soon as someone achieves a significant SUCCESS in the area of reuse, people change the rules ("No, THAT'S not really reuse...that's just using off-the-shelf software..."). The whole IDEA of reuse is to get to the point where you yank a bunch of preexisting software off a shelf and lash it together with a bit of glue, in exactly the same way that any other engineering discipline makes use of preexisting parts, subsystems, cards, chips, pistons, or what have you. We build software the way people built flintlock rifles before what's-his-name (damn!--not my day for Jeopardy questions--what was the name of the guy?) realized that building N identical triggers as a way to help build N identical rifles might be a good idea. We're treating software like a custom built item EVERY SINGLE TIME we build something. This is, not to put too fine a point on it, stupid. >For example the use of 4GLs, DBMSes, X windows, and math/GKS/stats/... >libraries to me it is all reuse. Reuse is much more prevalent than >people think, thanks to old fashioned concepts like servers (process >based reuse) and libraries (module based reuse). Well, it appear then that we're in violent AGREEMENT, since that's exactly how I define reuse too. >Usually, I suspect, reuse is meant to be applied to the narrow case >where one does custom sw development, which is no longer the case in >most commercial installation; nearly everybody nowadays is using DBMSes >and enjoying the benefits of not reimplementing from scratch data >management programs. Again, no argument from me. I'm getting this weird feeling that you wrote a 50 line post agreeing in total with my original post, and I just wrote a 50 line post agreeing with yours. Or did I miss something? -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
orville@weyrich.UUCP (Orville R. Weyrich) (06/16/91)
In article <1991Jun15.002253.10735@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >pcg@aber.ac.uk (Piercarlo Grandi) writes: > >Indeed! And what other term SHOULD we apply to using a DBMS instead of >writing our own? See, that's what's so ironic about reuse--like AI, >as soon as someone achieves a significant SUCCESS in the area of reuse, >people change the rules ("No, THAT'S not really reuse...that's just >using off-the-shelf software..."). The whole IDEA of reuse is to get >to the point where you yank a bunch of preexisting software off a shelf >and lash it together with a bit of glue, in exactly the same way that >any other engineering discipline makes use of preexisting parts, subsystems, >cards, chips, pistons, or what have you. We build software the way people >built flintlock rifles before what's-his-name (damn!--not my day for >Jeopardy questions--what was the name of the guy?) realized that building I'll try Eli Whitney for $0.02. Funny thing is that his two contributions to science and technology were the guns that made the Civil War so bloody, and the cotton gin that made using slave labor so cost-ineffective that slavery would have passed away of its own accord if given just a little more time. :-(. >N identical triggers as a way to help build N identical rifles might be >a good idea. We're treating software like a custom built item EVERY SINGLE >TIME we build something. This is, not to put too fine a point on it, stupid. > -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
brh@hare.udev.cdc.com (brian r hanson x6062) (06/18/91)
|> I'll try Eli Whitney for $0.02. |> |> Funny thing is that his two contributions to science and technology were |> the guns that made the Civil War so bloody, and the cotton gin that made |> using slave labor so cost-ineffective that slavery would have passed away |> of its own accord if given just a little more time. :-(. According to a book I have just been reading, you are wrong. Eli Whitney was not the first to have the idea of building bunches of identical parts and manufacturing stuff by putting together these parts. It was used in europe some years earlier. It also seems that his parts were not very identical but he did manage to obtain quite a lot of money from the government for this. Eli also did not invent the cotton gin but made an improvement to an existing gin to get it to work with the american cotton plants which was in turn made workable by yet another person. Finally, the connection between the cotton gin and the deepening of slavery is also not quite so clear cut according to this book. Out side the deep south the number of slaves per farm was lower in the years after the gin was introduced. Brian Hanson
munck@STARS.RESTON.UNISYS.COM (Bob Munck) (06/19/91)
In article Re: Reserve Demobilization System Built Around Reused Ada Code of 30 May 91 18:30:53 GMT chuck@brain.UUCP and John Goodenough @f98.n250.z1.FidoNet.Org write: >> Let's call a spade a spade. Maybe "rapid tailoring" or "rapid reengineering" >> is a more suitable term for this type of approach. > > I remember a paper some years ago >concerned with generating process control software by a Japanese company in >which they reported high levels of software reuse because they were tailoring >their standard software to each customer's needs. Should we call it reuse >when the end user is different, and otherwise call it enhancement? Toshiba called it "big profits." Note that their "Software Factory" was set up with the help of American consultants (from John G's old company) who couldn't sell the ideas in the US because they required planning beyond the next quarter's P&L statement. Why is John showing a FidoNet address? Have the hackers finally taken over the SEI? Bob Munck