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_20,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:5884 comp.lang.c++:14427 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: chief programmer team organizations was (c++ vs ada results) Message-ID: <1991Jun28.001040.22237@netcom.COM> Date: 28 Jun 91 00:10:40 GMT References: <1991Jun26.005625.25608@netcom.COM> <4212@ssc-bee.ssc-vax.UUCP> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} List-Id: dmg@ssc-vax (David M Geary) writes: > I believe that the ones writing the actual code should be the ones > that *architect the code they are writing*. No argument. Never said otherwise. BUT, the interactions between their code and the other code in the system is at a higher level of abstraction. An architect designs the superstructure for a skyscraper. The electricians called into wire the offices on the 56th floor may well decide among themselves how their going to accomplish this, but they have to do so within the OVERALL constraints as designed by the architect. For example, they have to wire it in 110v/60Hz--this is an architectural decision about how the 56th floor interfaces to other floors and to the outside world. The electricians should NOT take it upon themselves to make a change to this particular constraint, lest fires break out, sparks fly, etc. > We have GUI, client, and server software for accessing > (ultimately), Oracle over a network. That's an architecture. Who thought it up? Who owns it? > Of course, there is data constantly flowing between the GUI, > client and server. Therefore, architectural decisions concerning > interfaces between the 3 systems are decided by committee. Ah! Now, is everybody on the team also on this committee? If so, you either have a very large committee or a very small team. If, on the other hand, this committee is a small portion of the total team, then this is exactly the sort of architectural decision making by a small group of experts I've been extolling the virtues of all along. > 1. Break the system down into subsystems. > 2. Assign small teams to each subsystem. > 3. Teams are responsible for design/development of subsystem. > 4 .Interfaces between subsystems are designed by the developers of > the subsystems involved. I think we're in violent agreement on all points except possibly #4. I believe you want these decisions made by a very few people--if you have 50 subsystems (big systems have this many or more), then you either have a 50 person committee or you wind up with some architects who are responsible for the grand vision (yes, they're supposed to listen to what the developers have to say--they'd be idiots not to). I think 99% of this entire thread has been more a problem of nomenclature than of fundamental disagreement. -- *** 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++. *