CS4:COMP_ln1 Organising a programming project that involves more than one person proves to be a unexpectedly tough problem. There is some agreement on the reasons for this:- 1) Programming is almost entirely a matter of detail and all details must be correct. A broad overview, normally an important part of management, is rarely much use to anyone. 2) Programmer productivity is extaordinarily variable compared (say) to productivity in a chain of Fish and Chip shops. A high flyer with flair can contribute 10 times as much as a plodder. 3) Interfaces apparently specified to the satisfaction of everyone concerned can prove to have large loopholes. Consequently when modules are put together extensive redesign may be necessary. The traditional organisation chart, well proven in low tech industries, looks roughly like this:- ----------- | BOSS | ----------- / ! \ / ! \ / ! \ / ! \ / ! \ / ! \ / ! \ / ! \ --------------- --------------- ---------------- | Programmer1 | | Programmer2 | | Programmer 3 | --------------- --------------- ---------------- | | | | -------------- | Helper 1 | -------------- In a normal organisation liaison and decisions are the responsibility of the boss and can be conveyed quite simply down the chain. In a programming group many detailed decisions are, in fact, made by the programmers and rarely conveyed back to the boss. If the decisions are all conveyed up and down, the boss is liable to be overloaded. IBM have evolved a rather better grouping known as the Chief Programmer Team:- ------------- --------------- | Chief Pr |====================| Alter Ego | ------------- --------------- / ! \ \ / ! \ \---------------> / ! \ \ / ! \ \ / ! \ \ / ! \ \ --------- --------- ---------- ------------ | ToolM | | C.P. | | Tester | | Experts | --------- --------- ---------- ------------ The Chief Programmer is the most highly paid and runs the show. He is expected to write most of the critical code himself. He discusses his ideas and progress with his Alter Ego. This administratively inclined programmer produces working notes and the final documentation. AE also attends liaison meetings, handles routine administration and fights off the rest of the world. The Chief Programmer can call on the full or part time services of:- a) A Toolmaker who will produce service routines, test beds etc to order. These are normally well defined packages. In your project the TM might produce A list processing packages A Phrase structure compressing programme A lexical scanner etc b) A Code Polisher who improves the performance of tested code; removes internal consistency checks as they become unnecessary etc. In your project the Code Polisher would have only a minor role. c) A Tester who submits test programs . He notes and where possible fixes bugs. More difficult problems are passed back to the Chief Programmer. In your project an energetic tester is essential. d) Experts. Each team will need access to expertise relevant to the non-coding aspects of the problem. A PAYE package would need advice from a tax inspector. Your team will need to grow two experts - one on the esoteric aspects of Algol 60 and the other on the 370 Order Code. The ERCC's most sucessful programming groups have operated on this model for many years. The group is very flexible and is easily "bent" to accomodate personal quirks. It is also easy to introduce new people. The problem of reducing a large project into parcels suitable for a team of this sort is a black art outside the scope of this course. Those interested should peruse Fred Brookes amusing and revealing book. When working in a team, interpersonal relations are important and the dreary virtues help considerably. Be cheerful, willing, prompt, polite and helpful -- judge ideas, especially your own, objectively and try to do about 20% more than your share of the work. If your error or misjudgement wastes other peoples time apologise promptly and graciously. Some more concrete tips:- a) Check all input parameters that are likely to be passed to your code from other people's routines; reject silly ones with a clear message. This is much less time wasting than forcing others to plough through piles of diagnostic printing. b) Keep your source files tidy, up-to-date and well commented. Others in your group (not to mention examiners) will need to read them. c) Make new versions of source and object for all but the most trivial changes. Nothing is more destructive of group relationships than for A&B to be stalled because C made a minor "improvement" and then went off to the Pub. This course will guide you towards a typical hand crafted multipass compiler with about 6 components roughly sized as follows:- 1) {done} The compiler calling Command with Prompts and help text. This also connects the Algol text and sets up object,listing and work files. 2) { 5% } A lexical scanner that also produces the program listing. The main purpose of this step is to resolve the various lexical representations into a single convenient form. 3) { 15%} A simple Parser probably working top down to check the syntax of the Algol program and produce a parse tree. 4) { 50%} The main pass. Walk the parse tree and check for semantic errors. Allocate storage for variables and temporaries in a recursion proof manner. Generate an optimisable intermediate form as a list of triples or quadruples. 5) { 30%} Allocate the limited supply of general and floating registers then generate th IBM machine code. 6) {done} Shuffle the machine code into a valid EMAS object file and fill in the jumps. Background reading. a) "Up the Organisation" by Robert Townsend. (Paperback) RT was the man who made AVIS try Harder. This egotistical and amusing short account is well worth perusing. b) "The Mythical Man Month" by Fred Brookes. (In JCMB library) A classic. The account of the tribulation behind the production of IBM's OS360 Operating System. Facienda 1) Organise your team. 2) Write a 10 line IMP program on Amdahl. Set PARM CODE,PARMY and compile it looking at the code and intermediate triples. Compile again adding PARMZ to the options. this will give the Parse tree (difficult to follow) but also the register allocations and code for each triple.