1. CSC 395 – Software Engineering Lecture 5: Teams -or- How to Motivate and Manage the Unwashed Masses

2. Today’s Lecture Discuss teams, teams, and more teams Give you ideas for running the project Provide chance to discuss material from this week Get started thinking about homework Actual assignment available on the web Assignment is due in one week (Feb. 2 nd )

3. Lies, Darned Lies & Metrics Person-years is common measure of work Amount of work done by one person in a year Or work completed by 12 people in 1 month Or 4 people in 2 months + 1 person in 4 months One of the stupidest metrics ever Good news: we get to discuss a lot more Ignores that groups of people do not share a brain Working together takes communication that may (but will not) be made up by improved efficiency

4. Computer Science “Laws” Name for folk wisdom built up over years Brook’s Law Adding programmers to a team when a product is late makes the product even later. Weinberg’s Second Law If builders built buildings the way programmers wrote programs, the first woodpecker to come along would destroy civilization.

5. Teams in Programming Almost no software developed by 1 person Hence teams are universal issue Classroom time not spent working in teams Even less time discussing managing a team Two of the earliest published works: Democratic Teams Chief Programmer Teams

6. Democratic Teams Programmers tend to have outsized egos Consider code to be extension of themselves Name computers, modules, and algorithms eponymously Makes finding and fixing errors difficult: “Bug cannot be in MY code!” Instead rely on egoless programming

7. Egoless Programming Place emphasis entirely on team All code is owned by team Errors considered a normal and accepted event Team is responsible for finding and fixing bugs Develop single ethos  a group identity Modules will “belong” to the team as whole Maintain groups of up to 10 egoless programmers Can arise organically Often when there is nothing to gain personally Most often appears in academia & research

8. Chief Programmer Team Improve productivity by limiting communication Figure 4.3

9. Chief Programmer Team Chief programmer Successful manager and programmer Responsible for every line of code Performs architectural design, allocates coding, heals the sick, writes critical sections, handles interfaces, teaches cats to sing, performs all reviews, and blends in with mere mortals Back-up programmer Takes over if/when Chief Programmer is out For unknown reasons, does not leave for big $$$

10. Chief Programmer Team Programming secretary (librarian) Maintains all documents and deliverables Responsible for repository maintenance Content to spend all day doing paperwork Compiled, linked, & tested code (this was 1971) Programmers Write code Write more code This will never work in the real world

11. Teams in the Real World Need teams that consist of mere mortals Split chief programmer into 2 positions 1 position is managerial and 1 is technical

12. Teams In The Real World Must scale to modern teams of 20 to 120 programmers Whenever necessary, add more layers

13. Bring In Democratic Ethos Past result may encourage in-fighting and worst politics within organization Improve using democratic programming ideas

14. Synchronize-and-Stabilize Teams Used by Microsoft Teams of 3 – 8 developers & 3 – 8 testers Team responsible for overall task Work from specification through implementation Relies on daily synchronization step Programmer’s must check in code by 9 each day Errors between teams will be found that night Good for Microsoft and large open-source projects Common feature: excellent hackers

15. Pair Programming Teams Used in EXTREME Programming Always have person to bounce ideas off of One member creates cases, other does tests Project can survive a programmer leaving Provides mentoring when new people start Hard to develop ego when you do not even have computer in your cubicle

16. CMM-P Improves managing & developing workforce Each maturity level has its own KPAs Level 2: Staffing, communication and coordination, training and development, work environment, performance management, coordination Level 5: Continuous capability improvement, organizational performance alignment, continuous workforce innovation

17. Choosing Team Organization Exceedingly little study of team organization Instead rely on general group dynamic research Unclear whether optimal organization exists Involves range of personalities and environments Should differ with goals of the organization Really needs relevant experimental results Experiments here are hard, however

18. Comparing Team Structures

19. Discussion Which lifecycle model and team structure do you feel would be best on a project developing a start-of-the-art military communications system? Requirements will not change once started Reliability is very important Must be easy to adapt/fix/extend once delivered

20. For Next Lecture Monday’s lecture will discuss tools Tools to improve teamwork Tools to improve reliability Tools to improve productivity And give demonstrations of how these tools work