Readings - Week 5

R. Kraut, L. Streeter: Coordination in Software Development

What characteristics of software development do cause coordination problems?

There are several characteristics within Software Development, that make coordination harder than usual, listed below are the most significant ones.

Scale
Software Developments are often so large, that all the minor complexities and intricate details are never understood by one single person. Since it is often difficult to find such a person, companies have to look for alternate routes. The size of such a project, often lead to sub-groups forming rapidly, either through social preference, borders or organizational preferences. But this leads to the groups becoming distant from one-another which in turn leads to a wider rift between the notion of sharing and cooperative work. Compartmentalization can lead to errors, narrowness and insufficient opportunity for comparing knowledge and can reduce motivation in the future.

Uncertainty
Inherent uncertainty in software development, compounds the coordination problem. Since software development is not as structured and requirements often change throughout the lifecycle of the project, uncertainty becomes more and more prevelant. Users, analysts and domain usage also have a strong influence on the requirements and hence, uncertainty factor. It is often the case that designers and architects do not have the information required readily at hand, so the coordination effort between them and the analyst and users becomes tedious. It is also uncertain, since the different sub-groups working on the software all have different ideas on the functionality and aspects of the software.

Interdependence
Due to the nature of software modules, which in the end, need to mesh perfectly together to have a working program, interdependence becomes very important. Poor coordination in sub-groups developing integrating modules, could lead to failure in integrating the modules themselves.

Informal Communication
With the addition of the above-mentioned three problems, coordination becomes particularly difficult when you take the communication aspect into account. Coordination cannot become viable when there is no communication to convey the desired requirements of changes. Some of this communication is in the form of formal communication, often in the form of documents or technical specs...but these are found to be difficult for conveying a more personal approach. Informal comm is often better, making it easier to summarize, memorize and remember for future use, but could lead to the formal atmosphere being dropped altogether.

Ko et. al: Information needs in collocated software development teams

What information needs exist and how severe are they?

1. Writing Code
• C1 - What data structures or functions can be used to implement this behaviour
  
• C2 - How do I use this data structure of function?
• C3 - How can I coordinate this with this other data structure or function?
  
2. Submitting a Change
• S1 - Did I make any mistakes in my new code?
• S2 - Did I follow my team's conventions?
• S3 - Which changes are part of this submission?
  
3. Triaging Bugs
• B1 - Is this a legitimate problem?
• B2 - How difficult will this problem be to fix?
• B3 - Is it worth fixing?
  
4. Reducing the Failuree
• R1 - What does the failure look like?
• R2 - In what situations does this failure occur?
5. Understanding Behaviour
• U1 - What code could have caused this behaviour?
• U2 - What’s statically related to this code?
• U3 - What code caused this program state?
6. Reasoning about Design
• D1 - What is the purpose of this code?
• D2 - What is the program is supposed to do?
• D3 - Why was this code implemented this way?
• D4 - What are the implications of this change?
7. Maintaining Awareness
• A1 - How have resources I depend on changed?
• A2 - What have my coworkers been doing?
• A3 - What information was relevant to my task?

For the relevant severity of these cases, please refer to the diagram below: