From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_40,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:2727 comp.sw.components:303 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.lang.ada,comp.sw.components Subject: Re: Re^2: Ada 9X objectives Summary: Shorten *all* the time frames Message-ID: <16176@vail.ICO.ISC.COM> Date: 6 Oct 89 19:00:37 GMT References: <1373@blackbird.afit.af.mil> Organization: Interactive Systems Corp, Boulder, CO List-Id: jcardow@blackbird.afit.af.mil (James E. Cardow) writes about the problems in shortening the Ada language update cycle. His points were good, yet I was left with the feeling that there was something wrong underneath. I finally decided that it's this: > ...Consider the ten to twenty year development cycle for large projects... If you have a ten-year development cycle for a software project, you're going to be producing obsolete software! You can't help it. Ten years is just too long for anything tied to computers--the technology moves too fast. You've got to get software up and working, and performing at least some of the needed functions *soon*. You also need it to be adaptable, so that it can evolve as needs and technology change. What I'm getting at is that I think we're trying to address the wrong problem. Rather than trying to solve "How do we deal with long development cycles?" we should be solving "How do we shorten the development cycles?" -- +---------+ Dick Dunn rcd@ico.isc.com ico!rcd (303)449-2870 | In this | 4th annual MadHatterDay [10/6/89]: | style | Madness takes its toll |__10/6___|