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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8e4c13e427b7ab89 X-Google-Attributes: gid103376,public From: Marin Condic Subject: Re: how many programmers to change a lightbulb ? Date: 1999/11/18 Message-ID: <38342A03.6A35898D@pwfl.com>#1/1 X-Deja-AN: 550178707 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <38338F56.860DA47D@interact.net.au> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: condicma@pwflcom Newsgroups: comp.lang.ada Date: 1999-11-18T00:00:00+00:00 List-Id: G wrote: > Things like - when someone designs a major software project (I have been > looking > at the documents on domain analysis and other things at SEI) - it > appears as though the project is broken into teams - and each team need > only know about as much about the other team's work as they do to know > where what they are designing interacts with the other modules and > components of the system, that is - what contracts are being resolved. > As long as they return what is required to the system in the most > efficacious manner, everyone is happy. > > Is that right (however simple it may be) ? Won't there be problems with > geographically remote teams of programmers doing things separately such > that certain discontinuities might emerge with (the > compatibility/interoperability issues of) the various modules they > design ? In my experience with large software development efforts in Ada, you definitely get advantages in designing the interfaces between functional groups early on. To a large extent, it does allow developers of different subsystems to proceed independently. However, there is never a panacea which is going to make everything run flawlessly. It all goes back to the Tower of Babel. Or maybe Adam biting the apple. Inevitably, as a project progresses, different groups are going to discover things which make redesigning the interfaces necessary. Maybe just little tweaks - sometimes major overhauls. Independent development gets disturbed at that point. There will also come points in time when everybody has to synchronize up because you have to pull the various pieces together and subsystem A won't function correctly unless subsystem B is up and working as well. So team A is dependent on team B finishing their work. Eventually, you have to integrate everything and clearly defined interfaces help to make this less painful. But there is always functionality behind the interfaces and that requires coordination - thus making teams less independent. Just because the plug and the socket match, doesn't mean that you get the voltage you expected! :-) MDC -- Marin David Condic If you hurry you can, for a short time only, still find me at: Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/