The Effect of Programming Team Structures on Programming Tasks

1
The Effect of Programming Team Structures on
Programming Tasks

• Marilyn Mantei
• The University of Michigan
• EEL6887 Software Engineering
• University of Central Florida
• March 1, 2006
• Paul Michalek

2
Reference Sources

• Textbook Software Engineering Project
  Management, 2nd ed., edited by Thayer and
  Yourdon, IEEE Computer Society, 2000. pp333
  The Effect of Programming Team Structures on
  Programming Tasks", by Marilyn Mantei, taken from
  Communications of the ACM, Vol. 24, No. 3,
  Mar.1981, pp. 106-113.
• "Chief programmer team management of production
  programming" by Baker F. T. http//portal.acm.org
  /citation.cfm?id811127
• "Chief programmer teams Principles and
  procedures" by Mills, H.D. http//portal.acm.org/
  citation.cfm?id987262
• The Psychology of Computer Programming Silver
  Anniversary Edition by Gerald M. Weinberg
  http//www.amazon.com/gp/reader/0932633420/refsib
  _dp_pt/104-2697686-3831158reader-link

3
Classic Software Development Team Structures

• 1. Egoless Programming Team proposed by G.
  Weinberg in 1971
• 2. The Chief Programmer Team proposed by H. D.
  Mills in 1971 (implemented by F. T. Baker)
• Authors alternative
• Controlled Decentralized Team

4
Egoless Team Structure
Communication Channels
P
P
P
P
P
5
Analysis of EgolessTeam Structure

• 10 or less programmers who exchange code and
  test each others work
• Goals set by group consensus
• Leadership is dictated by Ability / Experience /
  Expertise

6
Egoless Strengths (based on small group
experiments and real life)

• Works well when the problem is very difficult
  more possibilities for creative solutions
• More communication helps solve difficult problems
• Results can be superior for difficult projects
• High job satisfaction
• Functions well for ongoing projects w/out time
  constraints

7
Egoless Weaknesses(based on small group
experiments and real life)

• Project completion takes more time because more
  communication is necessary
• May not perform well on simple tasks with time
  constraints
• Are Software Engineers egoless?
• Egoless Groups engage in riskier behavior (fault
  shift and peer pressure)
• - riskier solutions
• - riskier deadlines
• - easy to accept missed deadlines

8
Chief Programmer Team Structure
Communication Channels
CP
A
P
P
L
9
Analysis of Chief ProgrammerTeam Structure

• Small team 3 7 members
• Chief Programmer manages all technical aspects of
  the project
• Chief Programmer delegates to programmers
• Librarian handles documentation control, clerical
  support and communication support

10
Chief Programmer Strengths (based on small
group experiments and real life)

• Completes structured tasks more quickly than
  decentralized groups
• Can handle large and complex projects
• Handles time constrains well (much better than
  decentralized groups)
• Handles simpler tasks very well and quickly

11
Chief Programmer--Weaknesses(based on small
group experiments and real life)

• Centralized communication is vulnerable to
  saturation (overload)
• CP must be both a great people person and a great
  software engineer (rare)
• Team can struggle with low morale, and/or group
  cohesiveness
• Interfacing problems can crop up due to a lack of
  horizontal communication
• Perhaps less creative solutions result

12
Summary Egoless vs. C. P.

• The CP structure affords less communication --
  projects requiring horizontal communication fair
  poorly
• CP structure is perfect for simple or well
  structured tasks with rigid deadlines
• Egoless structure is perfect for highly complex
  problems where innovation is critical and time
  constrains are not

13
The Alternative Controlled Decentralized Team
Structure
PL
SP
SP
JP
JP
JP
JP
JP
JP
Communication Channels
14
Analysis of Controlled Decentralized Team
Structure

• Project Leader manages Senior Programmers Senior
  Programmers manage Jr. Programmers (subgroups)
• No limit to the number of developers
• Subgroups partitioned according to roles of the
  project (GUI, graphics, calculations)
• Subgroups exchange code, and communication only
  through their S. P.

15
Analysis of Controlled Decentralized Team
(continued)

• Gains benefits of Chief Programmer control and
  Egoless communication
• Centralized Team Leadership with Subgroups that
  are Decentralized
• Senior Programmers act as liaisons between groups
• For small or simple projects the CD structure is
  not necessary

16
Controlled Decentralized Strengths (based on
small group experiments and real life

• Communication problems are minimized (but dont
  go away completely between subgroups)
• The C.D. structure allows testing at multiple
  levels (and early) which leads to more reliable
  error detection
• Senior Programmers take some of the pressure off
  of the P. L. But can have a tough job --
  keeping the J.P. from conflict
• Works well on shorter projects

17
Controlled Decentralized Weaknesses(based on
small group experiments and real life)

• Projects that are not easily subdivided suffer in
  a C.D. structure
• Communication between sub-groups can suffer
  depending on the S.P.s
• When the task is very difficult the C.D.
  structure is less effective
• Problem-solving at lower levels may take longer
  (more communication, less concern for deadlines)
• Lower Job satisfaction than Egoless

18
Controlled Decentralized Structure -- Summary

• The Structure will work best for large projects
  which are reasonable straightforward and
  short-lived
• Highly reliable code can be expected, but not
  necessarily without group conflicts
• Project leader must still be extremely talented,
  holding ultimate responsibility for the success
  of the project

19
So Which Team Structure is the Best?. . . Or How
can we know which team structure to use?
Use the most important properties or
characteristics of the project to determine which
team structure to use.
20
Seven Properties of Software Projects

• Difficulty the complexity, number of decision
  points, number of interfaces, new technologies or
  methods
• Size lines of code or other quantitative measure
  of project size
• Duration lifetime of the development
• Modularity how well can the project be broken
  down into subtasks

21
Seven Properties of Programming

• Reliability how critical is the systems
  reliability, safety, robustness
• Time how critical are the time constraints and
  deadlines
• Communication how much communication with the
  user or other technical personnel (consultants)
  will be required

22
Recommended Team Structures

• E Egoless, CP Chief Programmer, CD
  Controlled Decentralized
• Project Characteristics
• Difficulty Size Duration Modularity
  Reliability Time Commun.
• Hi Low Lg Sm Short Lg Hi Low
  Hi Low Strct Lx Hi Low
• E E E E E
  E E
• CP CP CP CP CP
  CP CP
• CD CD CD CD CD
  CD CD

Note not all of the characteristics have been
tested in actual software environment.
23
Summary

• There is no perfect team structure for all
  Projects
• Project properties should be weighed against the
  team structure properties and then used to
  determine which team structure is best for a
  particular software project.

24
Case Study Which Structure would you implement?

• The project requires the re-engineering of an
  existing microcontroller Operating System to for
  a new multi-processor platform
• Much of the work will be structured based on the
  old system components
• A similar re-engineering project took less than 9
  months. However no deadline is given.
• The previous OS was developed with OOP
• The new system will be applied to ECG medical
  monitors

25
Rate this Project for each attribute

• Difficulty ?
• Size ?
• Duration ?
• Modularity ?
• Reliability ?
• Time ?
• Communication ?

26
How did you do?

• Difficulty medium ? (its been done before)
• Size medium/large ?
• Duration relatively short !
• Modularity High !
• Reliability High !
• Time no deadline !
• Communication moderate ?

27
Circle what you know for sure

• E Egoless, CP Chief Programmer, CD
  Controlled Decentralized
• Project Characteristics
• Difficulty Size Duration Modularity
  Reliability Time Commun.
• Hi Low Lg Sm Short Lg Hi Low
  Hi Low Strct Lx Hi Low
• E E E E E
  E E
• CP CP CP CP CP
  CP CP
• CD CD CD CD CD
  CD CD

Note not all of the characteristics have been
tested in actual software environment.
28
Recommended Team Structures

• E Egoless, CP Chief Programmer, CD
  Controlled Decentralized
• Project Characteristics
• Difficulty Size Duration Modularity
  Reliability Time Commun.
• Hi Low Lg Sm Short Lg Hi Low
  Hi Low Strct Lx Hi Low
• E E E E E
  E E
• CP CP CP CP CP
  CP CP
• CD CD CD CD CD
  CD CD

Note not all of the characteristics have been
tested in actual software environment.
29
Questions ?