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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: Tom_Hargraves@Raytheon.com Subject: Re: how many programmers to change a lightbulb ? Date: 1999/11/18 Message-ID: <8825682D.00824732.00@resmail70.ray.ca> X-Deja-AN: 550325219 To: comp.lang.ada@ada.eu.org Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@enst.fr X-Trace: menuisier.enst.fr 942968619 14594 137.194.161.2 (18 Nov 1999 23:43:39 GMT) X-Lotus-FromDomain: RES Organization: ENST, France X-BeenThere: comp.lang.ada@ada.eu.org Mime-Version: 1.0 Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Date: 18 Nov 1999 23:43:39 GMT Content-Disposition: inline Newsgroups: comp.lang.ada Date: 1999-11-18T23:43:39+00:00 List-Id: How to partition a project? This is an 'age-old' problem in software engineering. The dilemma used to be called bottom-up versus top-down design. Whatever you call it, the problems are still the same. A few advantages of the top-down approach are: 1. Nice 'clean' looking interfaces between nicely partitioned functions. 2. Management tasks which look like they can be controlled and split into separate groups. 3. A hierarchical software structure which maps to hierarchical management structures. 4. The user interface progresses quickly, and looks great. In short, it looks great on paper, especially to managers. BUT in practice you will find perhaps 10 to 20 groups who spend half their time solving the same problems. At the lower levels you will have 10 to 20 versions of the same software. If you've allowed unconstrained use of tasking you are doomed in the integration phase. Think of it as building a 10 floor building where each floor-designer is independently responsible for his/her percentage of the building foundations. Integration is hell. A few advantages of the bottom-up approach are: 1. Common software is produced for all to use. There is only one hash-search package to debug. There is only one linked list hander. There is only one scheduler etc. 2. There is one common interface to the plethora of user interfaces which must be supported over the lifetime of the project. 3. Common functions are identified quickly and provided for all to use. 4. Interfaces to COTS software are minimised and tightly controlled. In short, it looks great from an efficiency and maintenance point of view. BUT it's difficult to identify all the 'bottom' functions at day 1. Management don't like it because it's 'fuzzy', there is no hierarchy to manage. On a large project it could be months or years before the bottom-up approach shows tangible evidence that the project is bearing fruit. The user interface groups are delayed and delayed and end up calling X-windows/Win95 routines directly rather than wait for the platform independent routines the common software group keep failing to deliver in time... In practice you need a mixture. If it's a one-off project, small to medium size, with a short lifespan, then bias towards top-down. If it's a large project, which has an in-service life of 5 or more years and will be the mainstay of the company, bias towards bottom up. The key thing to remember is that it is the engineers who will turn this project into reality. In my experience 99.999% want to do a good job, and will naturally work hard in a supportive environment. Break it to them gently that they cannot use all the Ada features they'd like to 'try'. Organise parties. Keep them happy :-) Regards, Tom H. Marin Condic on 11/18/99 08:32:03 AM Please respond to comp.lang.ada@ada.eu.org To: comp.lang.ada@ada.eu.org cc: (bcc: Tom Hargraves/RMD/Raytheon/CA) Subject: Re: how many programmers to change a lightbulb ? 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/ _______________________________________________ comp.lang.ada mailing list comp.lang.ada@ada.eu.org http://ada.eu.org/cgi-bin/mailman/listinfo/comp.lang.ada