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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6960ceaa57428e2f X-Google-Attributes: gid103376,public From: Ray Blaak Subject: Re: Another important feature of Ada Date: 2000/11/19 Message-ID: #1/1 X-Deja-AN: 695586746 Sender: blaak@TORUS References: <3A12041B.BCFD8CA0@worldnet.att.net> <8uu6tf$63d$1@nnrp1.deja.com> <3A12BBC6.E3FDAB0F@averstar.com> <8v5dkm$ftt$1@wanadoo.fr> <8v78bm01p5t@drn.newsguy.com> <3A183756.485D5911@worldnet.att.net> X-Complaints-To: news@bctel.net X-Trace: news.bc.tac.net 974682400 209.53.149.68 (Sun, 19 Nov 2000 17:06:40 PST) Organization: The Transcend NNTP-Posting-Date: Sun, 19 Nov 2000 17:06:40 PST Newsgroups: comp.lang.ada Date: 2000-11-19T00:00:00+00:00 List-Id: James Rogers writes: > "pete@nospam" wrote: > > And in practice, it is only after running the program against the > > actual implementation that one finds for sure if the interface is > > the right one, also many times the interface is changed as development > > goes on. > > This of course reveals a process problem in several development > projects. The reason for changing interfaces is most often because > insufficient analysis and design work was done before beginning > implementation. The only time I have seen it necessary to change the > interface definitions has been when new requirements are levied on the > project after analysis and design is complete. This, again, is a > process problem. So says the official dogma. It sounds good on paper, but in my experience almost all interfaces need some modification after coding starts and people can actually start using it. I suppose you could say that I am unfortunate enough to have always worked on projects with process problems, but I don't think so. The need for modifications happen even on rabidly paranoid air traffic control projects whose process (I think) is excellent. Certainly the major design aspects of an interface should have been worked out in advance, but the details due to language and environment can drive usage patterns in particular ways that the designers simply cannot forsee until coding (e.g. "oh wow! this 3rd party library expects to be able to cache its data; I guess our data items need to be able to be cacheable across threads after all"). Instead, it is better to always expect change, and to struture your designs and abstractions so that they can readily be augmented, reimplemented, etc. New requirements always happen. Unexpected gotchas always get you. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul.