blakemor@software.software.org (Alex Blakemore) (06/20/91)
In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes: > One of the most successful Ada projects I'm aware of organized job > descriptions and responsibilities in such a way that a relatively small > number of exceptionally clever people was responsible for the architecture > (as captured in subsystem decomposition and subsystem interface specification), > each subsystem had a talented lead in charge of its implementation (but could > not alter the interfaces, which required an architectural decision), and > within each subsystem there was a team consisting of designers and programmers > (the designers designed package specs [class headers] and the programmers > implemented the bodies). It worked great...and one of the nicest things > about it was that it took the pressure OFF the folks who just wanted to > go program so that they didn't have to PRETEND to be architects. Nobody > felt insulted. Best of all, the staffing requirements when jobs are > set up this way are such that the availability of people is inversely > proportional to the expertise required--the less a person needs to know, > the more of them you hire, making it pretty simple to get the team > assembled (one or two hard-to-find architects, a small group of leads, > a bunch of programmers [many of them entry level and just starting to > learn the Ada language]). This makes sense and sounds like it can work well. It's really just the chief programmer teams from the Mythical Man Month by Fred Brookes. One obvious caveat - you really better have the right people in the chief programmer roles or you are sunk. This organization alone is not sufficient. I've been on projects at previous jobs with such setups and the upper roles were assigned to those that had been hired earlier, which wasn't the ideal criteria in my mind. They tended to restrict the flow of information between team members, which was great when they were able to create well designed independent work packages - but was a real hindrance when there were problems. I knew one very bright programmer who had unworkable designs pressed on him by the leader of his subgroup. He couldnt totally redesign it without her fighting every step of the way, even though it was absolutely necessary. He finally resorted to making the redesign but leaving a few obvious simple flaws that even she could detect, presenting the design to her for review and asking her help in solving those last sticky "problems". She saved her ego, the software was corrected but the poor guy at the bottom had to suffer through this several times and the lead got the credit when it worked. He would have done better to let the project fail if his goal was to advance in the organization. This project structure is not very forgiving if you place people too high or low in the hierarchy. If you are interested in a biting but accurate satirical treatise on the role of incompetance and hierarchies in large organizations, see the classic book - "The Peter Principle". -- --------------------------------------------------------------------- Alex Blakemore blakemore@software.org (703) 742-7125 Software Productivity Consortium 2214 Rock Hill Rd, Herndon VA 22070
s64421@zeus.usq.EDU.AU (house ron) (06/21/91)
blakemor@software.software.org (Alex Blakemore) writes: >In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >> One of the most successful Ada projects I'm aware of organized job >> descriptions and responsibilities in such a way that a relatively small >> number of exceptionally clever people was responsible for the architecture >> (as captured in subsystem decomposition and subsystem interface specification), >This makes sense and sounds like it can work well. It's really just >the chief programmer teams from the Mythical Man Month by Fred Brookes. >One obvious caveat - you really better have the right people >in the chief programmer roles or you are sunk. This organization The book "Software that Works" by Michael Ward recommends against this for exactly the reason you mention, among others. He feels that the programmers must be involved in design, and that design/programming should alternate, rather than one coming first in a big chunk followed by the other. That's my potted version, anyway. -- Regards, Ron House. (s64421@zeus.usq.edu.au) (By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)
fischer@iesd.auc.dk (Lars P. Fischer) (06/22/91)
>>>>> On 20 Jun 91, blakemor@software.software.org (Alex Blakemore) said:
Alex> This makes sense and sounds like it can work well. It's really just
Alex> the chief programmer teams from the Mythical Man Month by Fred Brookes.
Alex> One obvious caveat - you really better have the right people
Alex> in the chief programmer roles or you are sunk.
Please note that the Brookes book is not exactly new -- it's a great
book, one that every serious software professional should read, but
remember that some of the advise reflects state-of-the-art in the
early 70's.
I recommend DeMarco's "PeopleWare" book as a good introduction to the
management of development and the organization of people and teams. It
reflects a more modern approach to providing teams with a good spirit
by giving each person responsibility and the opportunity to develop,
plus providing good working environments. This is much more in line
with modern management practice.
Alex> If you are interested in a biting but accurate satirical treatise on
Alex> the role of incompetance and hierarchies in large organizations, see the
Alex> classic book - "The Peter Principle".
And please, please, remember that Parkinson's books are just that -
satire. They were never intended to be textbooks or solid advise on
management. They are hilariously funny and thought provoking at the
same time, but taking them literally would be a mistake.
/Lars
--
Lars Fischer, fischer@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Univ. of Aalborg, DENMARK. | these things. -- Calvinjls@netcom.COM (Jim Showalter) (06/22/91)
>He finally resorted to making the redesign but leaving a few obvious simple >flaws that even she could detect, presenting the design to her for review >and asking her help in solving those last sticky "problems". She saved >her ego, the software was corrected but the poor guy at the bottom had to >suffer through this several times and the lead got the credit when it worked. >He would have done better to let the project fail if his goal was to advance in >the organization. This project structure is not very forgiving if you place >people too high or low in the hierarchy. "Against stupidity, the gods themselves contend in vain." Sadly, this sounds like a fairly typical project. I swear, when I get in a bad mood I half believe the single most effective solution to what ails most troubled software development efforts would be to simply shoot every third manager. Arghh. On the other hand, the project I described in my earlier post was QUITE atypical. They chose Ada on its merits (didn't have to use it--just evaluated what was available and decided Ada was the only viable tool for solving their problem). They had a superb chief architect. They knew they were building 4 ships in a row, so they focused on reuse from the start as a MULTI-project objective (achieving, in the end, 70% reuse across the four projects and $117 million in savings [their numbers]). They made optimal use of Rational's technology. They were just wonderful. It's projects like this that make it all worthwhile...just wish there were more like it. -- *** 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++. *
jls@netcom.COM (Jim Showalter) (06/22/91)
s64421@zeus.usq.EDU.AU (house ron) writes: >blakemor@software.software.org (Alex Blakemore) writes: >>In article <1991Jun18.220609.19103@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >>> One of the most successful Ada projects I'm aware of organized job >>> descriptions and responsibilities in such a way that a relatively small >>> number of exceptionally clever people was responsible for the architecture >>> (as captured in subsystem decomposition and subsystem interface specification), >>This makes sense and sounds like it can work well. It's really just >>the chief programmer teams from the Mythical Man Month by Fred Brookes. >>One obvious caveat - you really better have the right people >>in the chief programmer roles or you are sunk. This organization >The book "Software that Works" by Michael Ward recommends against this for >exactly the reason you mention, among others. He feels that the programmers >must be involved in design, and that design/programming should alternate, >rather than one coming first in a big chunk followed by the other. >That's my potted version, anyway. Well, I certainly agree that design/programming should alternate--that's the basis of iterative development. On the other hand, I fail to see what this has to do with the notion that some people are better than others at design, and that those who are the BEST at design probably ought to be the ones making the most critical decisions on the project. If someone can provide me with an explanation for why junior programmers should be making architectural decisions affecting the entire project, I'm all ears. -- *** 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++. *
nagle@well.sf.ca.us (John Nagle) (06/22/91)
Real chief programmer teams are very rare. I've never heard of one
other than in Brooks' book. It's very different than having a lead programmer
or a system architect. It's organized like a surgical team. The chief
programmer personally writes most of the delivered code, and everything else
is set up to facilitate this. There is an administrator, who reports to the
chief programmer, to take care of mundane problems. A toolsmith creates
tools not part of the deliverable code. A language lawyer deals with
compiler and library issues. A tester tests everything. A librarian
keeps track of everything. All these people are subordinate to the chief
programmer.
It's too much of a culture shock for most organization.
John Nagle
jls@netcom.COM (Jim Showalter) (06/23/91)
>Alex> If you are interested in a biting but accurate satirical treatise on >Alex> the role of incompetance and hierarchies in large organizations, see the >Alex> classic book - "The Peter Principle". >And please, please, remember that Parkinson's books are just that - >satire. They were never intended to be textbooks or solid advise on >management. They are hilariously funny and thought provoking at the >same time, but taking them literally would be a mistake. Uh, you might want to check with Mr. Peter on that--I believe he was quite serious. And I've certainly seen the principle he elucidates in action in the real world (think of Dan Quayle...). -- *** 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++. *
jls@netcom.COM (Jim Showalter) (06/23/91)
> Real chief programmer teams are very rare. I've never heard of one >other than in Brooks' book. Given your description below, I don't find this surprising, since I find it impossible. Read on. >It's organized like a surgical team. The chief >programmer personally writes most of the delivered code, and everything else ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >is set up to facilitate this. Tommyrot! How on earth is a single human being going to write "most", or, for that matter, even a FRACTION, of the code on a project of significant size? I'm talking here of things like the multi-MILLION line FAA rewrite of the U.S. air traffic control system. No, what is needed is a single architect (or at least a very small number of architects on a tightly focused team) who set up the groundrules for the overall system. After that, a horde of implementors can hammer out the individual subsystems. What you describe sounds like something that MIGHT work, but only on a programming-in-the-small project, which I'm not particularly interested in (I view programming-in-the-small as a solved problem). > It's too much of a culture shock for most organization. As would be any unworkable scheme. ;-) -- *** 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++. *
feustel@netcom.COM (David Feustel) (06/23/91)
I think the FAA project will never be finished (except by decree). -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 EMAIL: feustel@netcom.com or feustel@cvax.ipfw.indiana.edu I voted for Bush once. As it's turning out, once was once too often.
jls@netcom.COM (Jim Showalter) (06/24/91)
>I think the FAA project will never be finished (except by decree).
Why? I was involved with that project, and they're basically on schedule
and have written gazillions of lines of stuff that works, and are
continuing to write more. What insight into that project do you have
that I do not?
--
*** 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++. *marc@dumbcat.sf.ca.us (Marco S Hyman) (06/24/91)
In article <1991Jun23.032353.8718@netcom.COM> jls@netcom.COM (Jim Showalter) writes: > Tommyrot! How on earth is a single human being going to write "most", > or, for that matter, even a FRACTION, of the code on a project of > significant size? I'm talking here of things like the multi-MILLION > line FAA rewrite of the U.S. air traffic control system. If one can imagine the system then one can build the system, just a little slower than two, or three. But in any case faster than 100. Every new person adds to the communications burden and increases the chance of a mis-communication causing something to be misunderstood. Misunderstandings lead to defects and system failures. I'd guess seven would be the top end, providing you have the right seven. Three seems to be a good number in practice. Charles Moore once said at a conference (I think it was Software Development '89) that he'd have no problem with SDI providing he was the one writing the software. (In forth?) And yes, I was involved in a project where three re-designed and wrote a system originally done by a group of 20 -- faster, with less problems, to the customers greater satisfaction, etc. And how many lines of code is TeX, Metafont, etc. Do you count the documentation? But size isn't the issue here. Quality is. If the customer wants it bad, that's how he's going to get it. // marc -- // home: marc@dumbcat.sf.ca.us pacbell!dumbcat!marc // work: marc@ascend.com uunet!aria!marc
g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) (06/24/91)
In article <25587@well.sf.ca.us>, nagle@well.sf.ca.us (John Nagle) writes: > Real chief programmer teams are very rare. I've never heard of one > other than in Brooks' book. It's very different than having a lead programmer > or a system architect. It's organized like a surgical team. The chief > [etc.] > > It's too much of a culture shock for most organization. > > John Nagle Real life success stories are more than welcome to this Software Engineering Teacher-type. I've found that Brooks' book seems to place all teams in some sort of Shangri-La, where managers are infinitely knowlegable and respect their programmers, customers are always happy, etc. Do chief programmer teams really work anywhere outside of a university classroom or in an experimental industrial setting? George C. Harrison, Professor of Computer Science Norfolk State University, 2401 Corprew Avenue, Norfolk VA 23504 Internet: g_harrison@vger.nsu.edu Phone: 804-683-8654
hargrove@asc.slb.com (Jim Hargrove) (06/24/91)
>>>>> fischer@iesd.auc.dk (Lars P. Fischer) writes: >>>>> On 20 Jun 91, blakemor@software.software.org (Alex Blakemore) said: Alex> If you are interested in a biting but accurate satirical treatise on Alex> the role of incompetance and hierarchies in large organizations, see the Alex> classic book - "The Peter Principle". Lars> And please, please, remember that Parkinson's books are just that - Lars> satire. They were never intended to be textbooks or solid advise on Lars> management. They are hilariously funny and thought provoking at the Lars> same time, but taking them literally would be a mistake. Well, maybe not. I notice that you are in academia. I find the Peter Principle works pretty well in BIG BUSINESS. BTW, the book was written by Lawrence(?) Peter, not Parkinson. On the other hand, Parkinson's laws seem to be VERY relevant to the real world. Work really does expand to fill time available. Extensions to disk space are also valid. -- -- jwh
nagle@well.sf.ca.us (John Nagle) (06/25/91)
jls@netcom.COM (Jim Showalter) writes: >> Real chief programmer teams are very rare. I've never heard of one >>other than in Brooks' book. >Given your description below, I don't find this surprising, since I >find it impossible. Read on. >>It's organized like a surgical team. The chief >>programmer personally writes most of the delivered code, and everything else > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>is set up to facilitate this. >Tommyrot! How on earth is a single human being going to write "most", >or, for that matter, even a FRACTION, of the code on a project of >significant size? I'm talking here of things like the multi-MILLION >line FAA rewrite of the U.S. air traffic control system. No, what is >needed is a single architect (or at least a very small number of >architects on a tightly focused team) who set up the groundrules for >the overall system. After that, a horde of implementors can hammer >out the individual subsystems. There's a school of thought that if you're writing something that big, your approach is wrong, and you need to develop some abstraction that makes the job smaller and moves most of the specifics into some kind of database. But what Brooks was talking about was a job of the size of an operating system kernel, a compiler, or a typical shrink-wrapped application. Many such jobs are something a single person could write with adequate support; examples of each of the above written by individuals exist. There are also examples of each of the above written by large teams, of course. With respect to the FAA application, it's entirely possible that the whole system will be obsoleted by something that has most of the smarts in the airplanes, perhaps a successor to ACAS with GPS inputs. Articles in Aviation Leak indicate that distributed systems are being worked on, especially for Europe, where cross-border ATC isn't well integrated. John Nagle
chuck@brain.UUCP (Chuck Shotton) (06/25/91)
In article <1107.286584f0@vger.nsu.edu>, g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) writes: > Do chief programmer teams really work anywhere outside of a university > classroom or in an experimental industrial setting? > > Approaches to running large scale development efforts appear to run the full spectrum from totally autonomous hacker collectives to dictatorial chief programmer authoritarian states. From practical experience, I can relate you a few success stories on some MEDIUM-sized (20-50 member teams) development efforts. An approach that seems to work well (with Ada) on data and user oriented application code tasks is this. First, and foremost, all members of the development team need to feel that they can make a constructive contribution to the DESIGN as well as the more mundane coding effort. This has the effect of getting everyone "signed up" to the grand vision of the system. All the programmers, designers, and systems engineers have some stake in the quality of the final product, because they are allowed to participate throughout the entire life cycle. The concept of an "elite" design team dictating system architectures to a "serf" class of coders is offensive to all but the most uncreative of Ada programmers. Before I get flamed to death, let me point out that on the tasks I've managed, programmed on, or designed, it was VERY important for management to be fully aware of the individual talents of each programmer. Then, structure the team in such a way that each (productive) member of the team can make a constructive contribution to the level of their abilities. Practical experience has also shown that most managers don't show the slightest inclination towards doing this. On the SSE project, our most successful development efforts involved teams of designer/developers who had cradle to grave involvement with the software's life cycle. Every task that got in trouble or resulted in a less than optimal solution was characterized by a few individuals mandating design decisions on a staff of talented (and ultimately, resentful) developers. These "problem" tasks also had serious trouble achieving a common vision of the final system. The moral of the story seems to be: Where practical, allow the greatest possible involvement in analysis and design activities by the people who are ultimately going to code the system. Not only is everyone "signed up" to the vision, but you end up educating a bunch of developers to be something more than code slaves in a body shop. [I have NO idea what this message has to do with comp.lang.ada, other than the fact that all of this "experience" was gleaned from Ada development tasks.] ----------------------------------------------------------------------- Chuck Shotton Internet: cshotton@girch1.med.uth.tmc.edu UUCP: ...!buster!brain!chuck "Your silly quote here." AppleLink: D1683 MacNet: shotton
erwin@trwacs.UUCP (Harry Erwin) (06/25/91)
g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) writes: >Do chief programmer teams really work anywhere outside of a university >classroom or in an experimental industrial setting? We used a chief programmer team on some tasks on the Site Defense Program in the mid-1970s at TRW. (This was the same program that was the basis for many of Barry Boehm's results during the same period. It seemed to work. -- Harry Erwin Internet: erwin@trwacs.fp.trw.com
jls@netcom.COM (Jim Showalter) (06/26/91)
nagle@well.sf.ca.us (John Nagle) writes: >jls@netcom.COM (Jim Showalter) writes: >>I'm talking here of things like the multi-MILLION >>line FAA rewrite of the U.S. air traffic control system. > There's a school of thought that if you're writing something that big, >your approach is wrong, and you need to develop some abstraction that makes >the job smaller and moves most of the specifics into some kind of database. There's a school of thought that people who belong to the other school of thought suffer from having never actually BUILT an air traffic control system. ;-) As far as developing abstractions that move the "specifics into some kind of database", I find "some kind of database" to be rather vague. An air traffic control system consists of a bewildering array of input sources (e.g. various kinds of radar) with various signal processing requirements, critical real time constraints, distributed heterogeneous networking, and a host of other nasties. In short--they're COMPLICATED. And to top it off, if they fail, people die. In large numbers. All at once. It may seem surprising, but the folks that build these things actually tend to be very bright, very motivated, and very concerned that they do it correctly. They aren't boobs, and there's a REASON why the code is big. They're not just writing code to write code. Whenever I hear someone say that these systems are "too big", I'm reminded of the scene in "Amadeus" where the emperor chides Mozart for using "too many notes", to which Mozart replies "Which notes would you have me remove, Sire?". Which lines of code would you have removed from an air traffic control system? The display code that manages the screens? The error detection and correction code? The code that interfaces with the various radars and normalizes the incoming data? I'm sure there must be literally hundreds of thousands of superfluous code in there somewhere... -- *** 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++. *
warack@dip.eecs.umich.edu (Christopher Warack) (06/26/91)
In article <1991Jun25.183805.9549@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >nagle@well.sf.ca.us (John Nagle) writes: >>jls@netcom.COM (Jim Showalter) writes: >>>I'm talking here of things like the multi-MILLION >>>line FAA rewrite of the U.S. air traffic control system. > >> There's a school of thought that if you're writing something that big, >>your approach is wrong, and you need to develop some abstraction that makes >>the job smaller and moves most of the specifics into some kind of database. > > ... > >is big. They're not just writing code to write code. Whenever I hear >someone say that these systems are "too big", I'm reminded of the scene >in "Amadeus" where the emperor chides Mozart for using "too many notes", >to which Mozart replies "Which notes would you have me remove, Sire?". >Which lines of code would you have removed from an air traffic control >system? The display code that manages the screens? The error detection >and correction code? The code that interfaces with the various radars >and normalizes the incoming data? I'm sure there must be literally >hundreds of thousands of superfluous code in there somewhere... I agree with Jim here. Yet there is even more to consider. I found that in building the satellite early warning system more support software was needed than operational software. The support software did things like database maintenance (on top of a DBMS), analysis, system evaluation, simulation, test support. I'm sure that FAA has similar needs in these areas. Even the operational software can surprise you. Our biggest chunk of code was spent in operator interfaces. When you have a multi-person interacting crew whose mistakes can be catastrophic, you're interfaces need to be simple and powerful enough to do the job fast... Another area that adds lots of software throughout a system is dependability. You can imagine the level of system dependability needed in an early warning system -- it don't do much good if it isn't running. I know that the FAA requirements are orders of magnitude tougher. To achieve this level in a large distributed system requires lots of monitoring, control and diagnostic software that itself must be reliable. Multi-million lines of code systems don't surprise me at all. But, keep in mind that the software doing the primary function is only a fraction of the system. -- Chris
jls@netcom.COM (Jim Showalter) (06/26/91)
>The concept of an "elite" design team dictating system architectures >to a "serf" class of coders is offensive to all but the most uncreative of >Ada programmers. I may be misunderstanding your post, but from what I'm able to glean from it, you don't think hierarchical decision making works on a project, and that the alternative is a sort of enlightened egalitarianism. If so, I disagree, based on my own experience. One does not expect bricklayers, welders, pipefitters, etc to also design a skyscraper, any more than one expects an architect to wire the offices. This always seems to get cast into a class-vs-class struggle, when in fact it is a simple matter of specialization and expertise. Not everyone can be an architect. On the other hand, not everyone can be a bricklayer (believe me--it's harder than it looks!). You reflect your own bias in the above quote, where the subtext appears to be that coding is an uncreative pursuit. Therein lies the error--coding is no more or less creative, no more or less rewarding, than architecting, plumbing, needlepoint, or any other human pursuit. If everyone tries to design the architecture, the result is not an architecture at all--it is a camel. Design by committee is generally regarded as a bad idea, yet you seem to be advocating a really big committee in your post. Or am I just confused? -- *** 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++. *
orville@weyrich.UUCP (Orville R. Weyrich) (06/26/91)
In article <1991Jun26.005625.25608@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >>The concept of an "elite" design team dictating system architectures >>to a "serf" class of coders is offensive to all but the most uncreative of >>Ada programmers. > >I may be misunderstanding your post, but from what I'm able to glean from >it, you don't think hierarchical decision making works on a project, and >that the alternative is a sort of enlightened egalitarianism. If so, I >disagree, based on my own experience. One does not expect bricklayers, >welders, pipefitters, etc to also design a skyscraper, Agreed. >any more than one But if I were a brick-layer, I would expect that there would be a suggestion box around somewhere for my input -- sometimes field observations are useful in catching oversights committed by the 'big boys'. Even better, the 'big boys' would practice "management by walking around." >expects an architect to wire the offices. This always seems to get cast Agreed. Also, it would not be cost effective. But I would be worried if the architect had no idea how to wire an office. -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
rmartin@clear.com (Bob Martin) (06/26/91)
In article <25587@well.sf.ca.us> nagle@well.sf.ca.us (John Nagle) writes: > > Real chief programmer teams are very rare. I've never heard of one >other than in Brooks' book. It's very different than having a lead programmer >or a system architect. It's organized like a surgical team. The chief >programmer personally writes most of the delivered code, and everything else >is set up to facilitate this. There is an administrator, who reports to the >chief programmer, to take care of mundane problems. A toolsmith creates >tools not part of the deliverable code. A language lawyer deals with >compiler and library issues. A tester tests everything. A librarian >keeps track of everything. All these people are subordinate to the chief >programmer. > > It's too much of a culture shock for most organization. > > John Nagle > Not to mention that it is impractical for one programmer to write the bulk of the code required for today`s applications. One of the major problems in developing large projects is making sure that everyone working on the project has the same 'vision' of what they are building, and how they are going to build it. This 'vision' spans concerns which are as diverse as high-level architecture to coding standards to testing methodologies. Providing this vision ought to be the job of the architect or a small group of architects. -- +-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for | | rmartin@clear.com |:R::R:C::::M:M:M:M:| my words but me. I want | | uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all | +----------------------+:R::R::CCC:M:::::M:| the blame. So there. |
dlw@odi.com (Dan Weinreb) (06/27/91)
In article <1991Jun21.222536.18888@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
If someone can provide me with an explanation for why junior programmers
should be making architectural decisions affecting the entire project,
I'm all ears.
I generally agree with the point you're making. In my experience,
what really happens is more complex than anything described in any of
these postings. Iterative development of software within a team is a
social interaction between people. It's not a question of "command
and obey", but a give-and-take with conversations and discussions. In
general, when I've been involved with this, the more senior
"architect"-type people end up having more say about design issues.
But if one of the other team members has a good idea, that idea can
certainly be used, and a good architect should pay attention to
everyone's ideas and be quick to credit and use ideas from anyone.
This is part of the process by which the more junior people become
more senior, and it helps keep everybody motivated and excited. An
important thing about the concensus process is to establish an
atmosphere of mutual respect and trust, so that when there are
disagreements on how to proceed, people will be able to compromise,
or to willingly give up their proposals and go along with someone
else's, without resentment.dlw@odi.com (Dan Weinreb) (06/27/91)
In article <1991Jun23.185449.24818@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >I think the FAA project will never be finished (except by decree). Why? I was involved with that project, and they're basically on schedule and have written gazillions of lines of stuff that works, and are continuing to write more. What insight into that project do you have that I do not? "No software is ever finished until the last user is dead." -- Old Canturbridian Proverb
dmg@ssc-vax (David M Geary) (06/27/91)
]> Who knows?
] Jim Showalter
]>The concept of an "elite" design team dictating system architectures
]>to a "serf" class of coders is offensive to all but the most uncreative of
]>Ada programmers.
]
]I may be misunderstanding your post, but from what I'm able to glean from
]it, you don't think hierarchical decision making works on a project, and
]that the alternative is a sort of enlightened egalitarianism. If so, I
]disagree, based on my own experience. One does not expect bricklayers,
]welders, pipefitters, etc to also design a skyscraper, any more than one
]expects an architect to wire the offices. This always seems to get cast
]
]If everyone tries to design the architecture, the result is not an
]architecture at all--it is a camel. Design by committee is generally
]regarded as a bad idea, yet you seem to be advocating a really big
]committee in your post. Or am I just confused?
I believe that the ones writing the actual code should be the ones
that *architect the code they are writing*.
We have GUI, client, and server software for accessing
(ultimately), Oracle over a network. We have 3 main guys
responsible for GUI, client, and server respectively. Each
developer designs (architects, if you will) his respective system
(GUI, client, or server). Each developer writes the code to
implement the design. Each developer also has a "sidekick" who
understands the system, and helps out from time to time writing
functions, porting code, etc.
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.
I like the idea of having a small group (possibly 1) of developers
responsible for a small subsystem. The requirements for the
subsystem are decided by implementors. The design and coding for
the subsystem are totally up to the group of developers. When the
subsystems interact, the issues are decided upon via committee,
with those directly responsible for the subsystems which have to
interact having the ultimate say in the design decision.
To me, this falls in line with OOP mentality. When one writes
modular, reusable code, a class is defined with a specific
interface. For instance one may have a class point, with an
interface consisting of point_Create(), point_Destroy(),
point_GetX(), point_GetY(), point_Move(), etc. How the point
class *implements* this interface is nobody's business but the
author of the class. The same thing can be applied to subsystems
in a software system.
In summary, then:
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.
Now, it may be that in a very large project, there are so many
subsystems that those dealing with the subsystems at the bottom
cannot see the light of day. In such a case, one may have system
architects who *work with* the developers of the subsystems, to
help design interaction between the subsystems.
However, to have one group design, and then hand the entire design
over to a group of "coders", I think, is asking for trouble.
Communication alone between the designers and the coders leaves
enough room for error to make me mighty nervous.
--
|~~~~~~~~~~ David Geary, Boeing Aerospace, Seattle, WA. ~~~~~~~~~~|
|-----------------------------------------------------------------------------|
|~~~~~~ Seattle: America's most attractive city... to the *jetstream* ~~~~~~|
|-----------------------------------------------------------------------------|dlw@odi.com (Dan Weinreb) (06/28/91)
In article <1991Jun26.005625.25608@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >The concept of an "elite" design team dictating system architectures >to a "serf" class of coders is offensive to all but the most uncreative of >Ada programmers. If everyone tries to design the architecture, the result is not an architecture at all--it is a camel. He did not say that everyone tries to design the architecture. He said, and I quote, First, and foremost, all members of the development team need to feel that they can make a constructive contribution to the DESIGN as well as the more mundane coding effort. This has the effect of getting everyone "signed up" to the grand vision of the system. All the programmers, designers, and systems engineers have some stake in the quality of the final product, because they are allowed to participate throughout the entire life cycle. The concept of an "elite" design team dictating system architectures to a "serf" class of coders is offensive to all but the most uncreative of Ada programmers. Please note the use of the phrase "constructive contribution" and the phrase "some stake" and the phrase "signed up". He did not say that everybody writes one paragraph of the design document. He did not say that everybody has to contribute equally, or that nobody is more influential than anyone else. As I said in a previous posting, the interaction between people on a project is a human social interaction, and as such is complex and subtle. It can't be reduced to simple formulas. Many goals must be taken into account, and many things must be balanced against other things. I agree strongly with Chuck Shotton's original posting, but I don't think it conflicts with the idea that in any project involving many people, it will be possible to identify a smaller subset of key architects. However, the meaning of "architect" isn't as simple as "anybody who isn't an Architect is locked out of the room when the Design is being Formulated, and the design, Fully Formed and Cast in Concrete, is handed to him for execution." In other words, progrmmers aren't separated into two hard-and-fast groups; it's a matter of degree. In my experience, that's the best way to organize a software project.
jls@netcom.COM (Jim Showalter) (06/28/91)
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++. *
dmg@ssc-vax (David M Geary) (06/28/91)
] Jim Showalter
]> David Geary
]> 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).
]
Well, you may have 50 people who, at one time or another, will
make contributions/decisions on the committee, but I don't think
you will hardly ever have all 50 people contributing at once.
When making a decision concerning architecture of the system, you
only have developers whose subsystems are directly effected making
decisions...
] I think 99% of this entire thread has been more a problem of nomenclature
] than of fundamental disagreement.
Yeah, probably so, but I think most people perceived that you
meant there would be an "elite" group of designers who turned the
design over to a "non-elite" group of developers to "code". While
this was probably not what you meant, it nonetheless has hit a
nerve.
--
|~~~~~~~~~~ David Geary, Boeing Aerospace, Seattle, WA. ~~~~~~~~~~|
|-----------------------------------------------------------------------------|
|~~~~~~ Seattle: America's most attractive city... to the *jetstream* ~~~~~~|
|-----------------------------------------------------------------------------|kevin@cbmvax.commodore.com (Kevin Klop) (06/29/91)
> I believe that the ones writing the actual code should be the ones > that *architect the code they are writing*. While I agree thgat the internal implementation of the sub module should be left up to the implementors, I disagree that they should be the ones to decide the external interface that the sub module presents to the world. Someone has to provide a cohesive view of the interfaces or else no sub module will be able to talk to any other sub module. It's this flow of information, or definition of interfaces, that I think of as architecting a design. > > We have GUI, client, and server software for accessing > (ultimately), Oracle over a network. We have 3 main guys > responsible for GUI, client, and server respectively. Each > developer designs (architects, if you will) his respective system > (GUI, client, or server). Each developer writes the code to > implement the design. Each developer also has a "sidekick" who > understands the system, and helps out from time to time writing > functions, porting code, etc. > > 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. Aha! here's where all of a sudden, we're back in agreement. Your three guys are acting as the systems architects as well as architecting their own committee. While I feel that someone has to architect the overall system, that does not preclude that the overall architects aren't also the people that implement and/or architect subsystems as well. > > I like the idea of having a small group (possibly 1) of developers > responsible for a small subsystem. The requirements for the > subsystem are decided by implementors. The design and coding for > the subsystem are totally up to the group of developers. When the > subsystems interact, the issues are decided upon via committee, > with those directly responsible for the subsystems which have to > interact having the ultimate say in the design decision. > > To me, this falls in line with OOP mentality. When one writes > modular, reusable code, a class is defined with a specific > interface. For instance one may have a class point, with an > interface consisting of point_Create(), point_Destroy(), > point_GetX(), point_GetY(), point_Move(), etc. How the point > class *implements* this interface is nobody's business but the > author of the class. The same thing can be applied to subsystems > in a software system. > > In summary, then: > > 1. Break the system down into subsystems. Correct - but that's part of the architect's job - defining sub-systems and their interactions/interfaces. > > 2. Assign small teams to each subsystem. > > 3. Teams are responsible for design/development of subsystem. Within the guidelines of the system architecture. > > 4 .Interfaces between subsystems are designed by the developers of > the subsystems involved. Nope - part of deciding what are subsystems is also deciding how they interact/interface. This should be BEFORE the subsystems have had people assigned to implement them. > > Now, it may be that in a very large project, there are so many > subsystems that those dealing with the subsystems at the bottom > cannot see the light of day. In such a case, one may have system > architects who *work with* the developers of the subsystems, to > help design interaction between the subsystems. > The way I see it is a hierarchical series of architects. A couple of people that take the problem and define some modules and interfaces between the modules. Then, these modules, along with the interface definitions, are handed to module architects which define modules within the module, and define how they interact. These modules are handed to programmers who realize the design in computer code. Note that nowhere does this state that the programmers implementing the code aren't also the people architecting the "next higher level" as well. > However, to have one group design, and then hand the entire design > over to a group of "coders", I think, is asking for trouble. > Communication alone between the designers and the coders leaves > enough room for error to make me mighty nervous. > > Remember that OOP is NOT a design philosophy, it's an implementation methodology. While one can design in such a way as to make OOP easier, a design doesn't HAVE to have any knowledge of the implementation methodology, much like algorithms don't care what language they're implemented in. Design philosophies tend to fall into "Top-down", "Bottom-up", or the vastly popular, "Inside out" (wherein the code starts somewhere in the middle between top and bottom and then grows in both directions). Don't confuse design with implementation. -- Kevin -- Kevin Klop {uunet|rutgers|amiga}!cbmvax!kevin Commodore-Amiga, Inc. Ever feel like a lemming that's afraid of the water? Disclaimer: _I_ don't know what I said, much less my employer.