1. CSE 350 - Software Design and Engineering Jonathan M. Smith http://www.cis.upenn.edu/~jms

2. Administrative lBulk Packs are at the copy center lHandouts on UNIX have been distributed lI will go into some depth on UNIX Thursday so please read ahead lhttp://www.cl.cam.ac.uk/~jms77/STRIPOS.html

3. Groups: lNeeded when “superprogrammer” is not enough - complexity too high lMaybe for reasons of specialization lMaybe for reasons of redundancy lIs there a principle for selecting groups, their task and their structure (we’ll look at two) lDoes adding more people speed it up?

4. Background - Fred Brooks lLed IBM/360 OS development lIBM had bet the company on the 360, and it was running late lEventually finished, hugely successful lBrooks captured some lessons in “The Mythical Man-Month” (selected chapters in bulkpack)

5. What is a man-month? lIn some lines of work, a project can be estimated as requiring x “man-months” lGoal is planning/cost estimation lProject going too slow, underestimated man-months required, add more people lIt doesn’t work with software! lBut why?

6. Abstract Software Creation lRead/Converse/Listen lUnderstand Problem lCode a Solution - test, interoperate, etc. lConsiderable communication lFor number of people n, grows as n**2

7. Succeeding with less communication lDivide up programming responsibilities, and assign to groups lGroups can take a number of different forms lThey all reduce communication using structure lExample: hierarchy & specialization, as in Brooks’ “Chief Programmer Team”

8. Chief Programmer Team lModeled after “surgical team” lSpecialists, including a broadly-skilled specialist in managing the other specialists - “Chief Programmer” lOther roles: -Assistant to the Chief -“Language Lawyer” -Librarian

9. Chief Programmer lResponsible for system lFocal point for management lHas done it before - experienced - often as assistant to another programmer lResponsible in team for strategy and high-level decisions, interface to other CPTs

10. Assistant lMore on top of details lIn-line to become Chief Programmer on next system lCovers for Chief when needed lUnderstands strategy / masters details

11. Language Lawyer lE.g., “C” guru lKnows language details lKnows what’s possible - may know a lot about hardware lOften can “find a way” lSometimes shared among projects - maybe “alpha geek” :-)

12. Librarian lChecks code in and out lResponsible for versioning lKeeps documentation also lMay work to keep documentation consistent with code! lPoint of focus for project information

13. Virtues of approach lClear lines of communication lClear responsibilities lClear specialization - use of skills lWeakness is “stiffness”