1.1.1 Internal Communications

Brook’s law is well-known truism of software development:

"Adding manpower to a late software project makes it later. – Fred Brooks, _The Mythical Man-Month, 1975

Why?

Brooks argues that

• Complex projects cannot be decomposed into subprojects that can be solved independently without communication.

He suggests that partly, this is an attribute of the problem being solved.

• Essential versus accidental complexity

  He suggests that sometimes we add complexity by our choices of process or design, but that some problems are just plain complicated. As a consequence, he suggests that there is an

  • irreducible number of errors

    that we will always commit along the way, and that this is independent of the number of people we have working.

  But he also argues that

• More personnel implies more communications paths

  • $n$ staff have \( \frac{n(n-1)}{2} \) potential communications paths.

Reducing Internal Communications Costs

Our options are limited

• Keep teams small, or
• Structure the teams in ways that facilitate the most critical communications paths

1.1.2 External Communications

We can divide this into

• communications with the development team’s own management
• communications with the eventual users of the software

Historically, the former has been emphasized

• visibility of the process is a major factor in Waterfall & Spiral

Over time, more and more emphasis has shifted to communications with the users.

Users, Customers, and Stakeholders

“Users” is an incredibly vague, catch-all term that serves to hide as much as it reveals.

Avoid it when possible.

• Customers are the people who have the authority to accept or reject the system, to pay for it or not.

  “Pay” is not necessarily a simple monetary transaction.(e.g., internal projects)

• Stakeholders are the people with an interest in the structure and behavior of the system.

Example:

• A company’s upper-level management approves budget to develop a system. They are the customers.

• The output of the system is a series of reports used on a monthly basis by the company’s middle and low-level managers. They are stakeholders, because they have an interest in the content and format of those reports.

• Much of the input of the system will be supplied by the company’s clerical staff, sales people, and technicians. They are also stakeholders, because the system will directly impact their daily jobs.

We look to customers for general guidelines on what will make the valuable and acceptable to them.

We look to stakeholders for much of the insight into how the system needs to work.

2 General Organizations

There are a few “obvious” ways to organize developers into a team.

One might be the basic democracy (or anarchy) of everyone working as peers.

• You probably don’t need very large teams before this gets unwieldy.

2.1 Hierarchical Team Organization

• One team per major subsystem
• Teams report to managers
• Managers report to one or more levels of higher managers

Dangers of Hierarchical Teams

• Distance between teams (where real work is done) and higher mgmt may hide problems.

  I like van Vliet’s example:

  "The following scenario is not entirely fictitious:

  • bottom: we have severe troubles in implementing module X;

  • level 1: there are some problems with module X;

  • level 2: progress is steady, I do not foresee any real problems;

  • top: everything proceeds according to our plan."

• Level in hierarchy often equates with rank / rewards

  • Engineers either cannot rise in level or are forced to abandon their primary skills to be managers

2.2 Matrix Organization

• Staff are assigned specialized roles based on skill sets
  • e.g., architects, designers, analysts, testers
  • Team managers address general ability of team to perform role
• Subprojects identify required role players
  • Teams with commonly required roles move among multiple subprojects
  • Project managers oversees specific project

Clearly this has limited benefit if an organization is so small that they have just one architect, one tester, …

In this model, team members with critical skills can be swapped from project to project depending on where each project is within the SDPM. For example, a good architectural designer may leave projects once they enter the high-level design phase.

Dangers of Matrix Organization

• Restricted inter-role communication
• Management clashes
  • project managers may clash with the higher managers that assign people via the matrix.

3 Software Team Organizations

Anarchy, hierarchy, and matrix are all pretty generic forms.

Next we look at some specific organizations that have been attempted.

3.1 Chief Programmer Teams

Mills (1970)

• Motivated in part by studies showing vast differences in productivity between different individuals within an organization

  Programming productivity studies have found that the “best” people in many organizations were orders of magnitude more productive than the average. (Not than the worst, but than the average.)

  Some of this correlates with varying degrees of experience, both in general and with the specific problem domain and development environment at hand. But some of this seems to indicate that some people just are better at this than others.

• Aims to allow the potentially most productive people to work unhindered

Organization of the Chief Programmer Team

• Chief programmer is team leader
  • responsible for design and critical parts of the implementation
• Assistant programmer assists chief and does rest of the implementation
• Librarian handles documentation, deployment, code management, etc.
• A few specialists can augment the team

Observations

• A very coding-centric view
• High stress on chief
• Low level of satisfaction for remainder of team
• Does not scale well to large projects.

3.2 SWAT Teams

SWAT == Skilled With Advanced Tools

A team organization for iterative process models

• Small team, sharing a common workspace
• Heavy tool support
• Team leader is “first among equals”

3.3 Agile Teams

• Small teams, often sharing a workspace

• Typically, one team manager

• Often includes customers/stakeholders or their designated representative as a team member.
• Team sets their own best practices
  • selects tools
• Emphasis on self-management, self-motivation
  • Professional pride

3.4 Distributed Teams

Common in open-source development

• Small core team responsible for project “vision”
• Associated developers submit patches, changes, etc.
  • Must be approved by core team to be merged into official project
  • A pull request is a request for others to check out a proposed change.
• Users submit bug reports and feature requests
  • May be prioritized by core team.
  • But an associated developer is not prohibited from working on a low-priority request.

Total team can be huge and diverse.

Closing Thoughts

• If you were formed into groups, this week, to work on a project, how would you organize yourselves?

  • Would it match any of the organizations shown here?

• Does it make a difference to your answer whether this is a distance course?