Xref: utzoo comp.sys.apple:5585 comp.sys.ibm.pc:14685 Path: utzoo!mnetor!uunet!husc6!bloom-beacon!bu-cs!madd From: madd@bu-cs.BU.EDU (Jim Frost) Newsgroups: comp.sys.apple,comp.sys.ibm.pc Subject: Re: A Nutty Idea (Really: managing big programming projects) Message-ID: <21866@bu-cs.BU.EDU> Date: 21 Apr 88 02:54:23 GMT References: <231@unsvax.UUCP> <6276@watdragon.waterloo.edu> <138@bud.UUCP> <1722@desint.UUCP> Reply-To: madd@bu-it.bu.edu (Jim Frost) Followup-To: comp.sys.apple Organization: Boston University Distributed Systems Group Lines: 121 In article <1722@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: | Coordinating different workers on the same project is difficult and | time-consuming. With 3-5 workers, it's a full-time job. With | more, because of the combinatorics involved, the complexity rises | exponentially (*not* linearly). Read "The Mythical Man-Month" by | Frederic P. Brooks for a thorough discussion of this issue. This is a good text, however it is somewhat dated and techniques have changed somewhat. The basic problems discussed have NOT. When you deal with a large programming project, the way to go about it is to build teams of about 10 people. Fewer than 5 should be programmers. One person is a lead programmer, another is an assistant, and two or three are auxiliary programmers. You should have one manager (preferably with programming experience), a secretary, and someone for maintenance. Depending on the project, you might want other people as well. You break up the project ONLY IN PLACES THAT ARE RELATIVELY INDEPENDENT, and give each portion to a different programming team. Otherwise the communications costs rise exponentially and things slow to a crawl. This is what happened in the OS/360 development, which is what the book suggested above talks about. The way to go about getting a late project done faster is to continue as you were, not to hire more people. That causes slow-down that is unbelievable -- new people have to be taught, and they increase communications costs. This is a mistake that is made repeatedly. Back to programming teams. Why build them as I suggest? First, cream-of-the-crop programmers are hard to find, but really can get the work done. Thus, you let them do most of the all-out hacking necessary to get the job done. You have an assistant programmer who works closely with the lead programmer. He should be familiar with the work of the lead programmer. This is because good programmers have this tendency to follow large monetary offers. If your lead programmer steps out, the assistant can take over with minimal hassle since he's already familiar with the code. The assistant can also work on periferal tasks that the lead programmer needs done but doesn't have to do himself. Since he's familiar with the work of the lead programmer, he's not likely to have many misunderstandings with regards to subroutine calls, etc. Auxiliary programmers are there to get rid of tedious portions of coding that must be done to make things work. They don't have the experience of either the lead or the auxiliary, but they will gain experience as they work and they will be pretty familiar with what's going on -- thus they can replace the assistant programmer with a minimum of hassle if either the assistant or the lead programmer should leave. Secretaries and managers are around to get the paperwork done. They talk to other programming groups and inform upper management of status. This keeps the programmers free to program, which is what they like to do and what you're paying them for. Managers also handle things like funds and requests. KEEP MUNDANE TASKS AWAY FROM PROGRAMMERS. The more silly little things they have to do, the less programming they'll get done. Maintenance people do things like system management that would slow programmers down but which must be done. Often maintenance can be spread between programming groups to reduce costs. If you undergo a programming project following guidelines like these, you'll find it goes smoother and things get done. This type of group is robust enough to withstand even the removal of the lead programmer, and has very low communications costs. It has been used effectively in many programming projects. Other tips to keep in mind: Take your estimate of how long it's going to take to get something done and multiply it by at least 1.5 before telling anyone. You'll be much more accurate, which will please management. Personally I recommend multiplying by two, following the rule "the first 90% of the job takes 90% of the time, and the remaining 10% of the job takes the second 90% of the time." If you multiply by two, you'll probably finish early :-). Before starting the project, plan out the architecture completely before you start. Examine different architectures. Allow those working on the project to submit ideas. You'll come out with a much cleaner program; often this can help in the partitioning of work into programming groups. Even using 20% of your allotted time might be useful, since a well-designed project is easier to implement and debug. Leave programmers alone. The biggest mistake you can make is to hassle them (unless, of course, they consistently don't show up for work and instead go play pool). A programmer who's sitting in a chair doing nothing is probably brainstorming. Don't make programmers stick to 9-5 schedules unless absolutely necessary. Good programmers will still put in the hours, but often prefer to work off-hours. Most of my best hacking is done at 2am and in marathon stretches of over 24 hours; I've found a good many others who think the same. Don't make programmers dress up. Let them be comfortable. They're not going to be seen by the public anyway. Dressing up management is a good idea, since uniformity in management usually leads to better productivity. Programmers tend to be more intimate, and uniformity leads to stress and not increased productivity. Stress clean, reasonably documented code, but do not strictly enforce a particular programming style. Programmers won't follow it anyway, so why waste your time. If a programmer's style is readable, leave it as it is. Most programmers use nearly the same code formatting style nowadays anyway. As for the programming project that was brought up, Geoff is correct. You'd be dreaming to think that a lot of programmers each devoting a little time would make it work. To make the operating system, you need a small team of good OS hacks with a lot of time. A distribution of effort would work while developing the applications for such an OS, though -- this has been clearly demonstrated by the MINIX people. | Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff jim frost madd@bu-it.bu.edu