+

Working With Others

Systems Analysis and DesignMichael Heron

+Introduction

One of the ‘lesser known’ skills in being a developer is the ability to work with other people.

The reclusive hacker is rarely something you genuinely encounter.

And not just definitionally…

On one level, that’s impacted by your own social skills.

On another, it’s do to with the systems you have in place. Software Collaboration

+Step One: Collaboration

We throw around the word ‘collaboration’ quite a lot in modern life. Modern development is often a collaborative affair.

The various open-source movements are excellent examples of collaboration in software development. This decentralised approach to programming was widely

considered to be impractical before Linux proved it viable.

However, it has been shown to be useful and powerful in other contexts too. Look at Wikipedia as an example of a community

developer, peer reviewed (well…) collaboratively developed information resource.

+Step One: Collaboration

Every project has its own systems in place for supporting (or inadvertently discouraging) collaboration.

There are software tools: Wikis Mailing lists Bulletin Boards Source Control

These are only part of the necessary infrastructure.

What also matters is how you use them, and how you work together as a team to reach certain goals.

+Step One: Collaboration

The social context of collaboration is also vital. How is authority earned in a project?

Authorial leadership, such as in Wikipedia? Tribal elders, such as in Linux?

Who has ownership over code? Everyone? No-one?

How does everyone keep up to date with changes?

The nature of your colleagues will greatly impact the nature of collaboration. The reason we often make you do group work in university

is not always because it’s expected to go swimmingly.

+Step One: Collaboration

+Step One: Collaboration

People may not want to collaborate. The environment may not facilitate it.

There may be a generational gap in terms of familiarity with collaboration. Younger developers tend to be more comfortable with collaboration.

Styles of collaboration may vary. Co-written? Serially written? Separately written then merged?

People may actively disapprove of collaboration. Some authors have written of the encroaching ‘digital Maoism’, for

example. Lanier, J. (2006). Digital maoism: The hazards of the new online

collectivism. Edge

+Step One: Collaboration

First and foremost, the will to collaborate must be present. Environments in which collaboration is not properly rewarded will

not be fertile grounds for collaboration.

Start with the people, not with the technology. ‘If We Build It, They Will Come’

No, they won’t. People need to know what the technology is for.

Once the social context is conducive to collaboration, build the software support.

See Orlikowski (1992)’s paper ‘learning from notes: organizational issues in groupware implementation’ for a great discussion of a failure in collaboration technology.

+Step One: Collaboration

Collaboration in modern development is facilitated by a large suite of collaboration software. A wiki can be invaluable for allowing people to participate

in wide-scale design. Many development organisations have their own forward-

facing wikis and blogs.

Choose the tool for the job on the basis of what people need to do. If no-one sees a need to write the blog, don’t expect it to

be used.

Setting yourself up with the right infrastructure for working together will save a lot of heartache down the line.

+Collaboration and Open Source

The open source movement is a tremendous source of insights into the nature collaboration. Why do people contribute?

Altruism? Intangible benefits? How do people contribute?

Self-selection How is the quality ensured?

Meritorious advancement What’s the benefit?

Linus’ Law, distributed effort, ‘wisdom of the crowds’, broader base of feedback for ideas and perspectives.

+Collaboration and Open Source

The exact configuration of collaboration elements in your own projects will depend on the environment. Some commercial software houses work on open-source

principles. Some open-source projects work like volunteer code shops.

Choosing the right combination of collaboration elements is a key factor to success.

Just because these techniques are considered to be most effective when used for code doesn’t mean that’s all they can be used for. In your groups, you need to consider how collaboration is

going to work given your various skills, availabilities and confidences.

+Step Two: Development

When working with other people in development, there are vital etiquettes.

Pay heed to the Ten Commandments of Egoless Programming http://articles.techrepublic.com.com/5100-10878_11-10457

82.html

Even if your style is not egoless, these rules are in place for a reason.

Think of these are ‘rules for dealing with people in professional contexts’.

Criticism can be hard to take. But most people don’t give it very well.

+The Ten Commandments

1. Understand and accept that you will make mistakes.

2. You are not your code.

3. No matter how much "karate" you know, someone else will always know more.

4. Don't rewrite code without consultation.

5. Treat people who know less than you with respect, deference, and patience.

6. The only constant in the world is change.

7. The only true authority stems from knowledge, not from position.

8. Fight for what you believe, but gracefully accept defeat.

9. Don't be "the guy in the room.“

10. Critique code instead of people -- be kind to the coder, not to the code.

+Step Two: Development

For all of these rules, you can replace ‘code’ with <any creative output>.

Following these commandments will lead to a more pleasant working environment. Collaboration is most easily facilitated between people who

like (or at least, respect) one another.

Taking the decision to collaborate is a psychologically risky manoeuvre for some people. The wrong environment will kill the impulse.

Within this module, your motivations aren’t entirely pure. You’re pretty much being told to do this.

+Step Three: Integration

Assuming there is the will to collaborate and the environment exists to facilitate collaboration, there exists the task of actually collaborating. This often involves multiple people working on the same code

files.

The importance of source control in a multi-developer cannot be over-emphasised. Industry developers in general are often woefully disappointed

in how little this gets emphasised in education. Source control systems also have a place beyond code.

Document control is as important as anything else. http://

en.wikipedia.org/w/index.php?title=Systems_analysis&action=history

+Step Three: Integration

The basic problem of multi-developer collaboration is something like this: Developer A downloads awesome.java from the main file server. Developer A makes some changes to awesome.java to fix a problem. Developer B downloads awesome.java from the main file server. Developer A uploads the fixed awesome.java to the file server. Developer B makes some changes to awesome.java. Developer A downloads uses_awesome.java from the file server. Developer B uploads the fixed awesome.java Developer A fixes uses_awesome.java. Developer A uploads the fixed uses_awesome.java.

Hilarity Ensues! This is a combination of a technical and social problem, and

both need to be addressed.

+Step Three: Integration

After this sequence of events, those two files (and everything that uses them) no longer have integrity. They may work, or they may not. You can’t be sure which is

which.

The problem here is that nobody has actually done anything wrong. We’re assuming both developers made no mistakes.

The problem is in the nature of the collaboration. It’s not set up to limit risks and maximise benefits.

Good software design can help mitigate this problem. Test driven development means flaws will be found quickly. Continuous Integration (to come) ensures that you know

when your build is no longer working.

+Step Three: Integration

Source control is a system that resolves this problem.

At the simplest level: All files in a development are locked. Developers can check out files they are working with.

Only one developer can check out a file at any one time. Only the developer who has a file checked out can save

an updated version. When the developer has finished, they check in the file.

And add a description of what they have changed.

More complicated systems allow for concurrent modification and merges.

+Step Three: Integration

Source control usually comes bundled with a secondary revision control system. Every change that is made is logged to the

system. Usually using a difference compression algorithm.

Files can be reverted to older versions with a simple command. This is a feature shared with most wikis, which are

revision control systems in themselves. Broken code thus is easily rolled back to its last

working version. Moreover, you can see who’s been working with

the file.

+Step Three: Integration

Source control is not a flawless solution. Developers often forget to check in files. Developers sometimes pre-emptively check out files. Comments on changes are sometimes not helpful.

A real life example, from… *cough*… someone: date: 2007/06/05 20:06:51; author: XXXX; state: Exp; lines: +88 -2 Changed some stuff.

It is not a substitute for good developer communication. It’s a complement.

It does however ensure that accidental code collisions are removed.

The rest of the problems are social environmental problems.

+Step Three: Integration

Imagine our original scenario, rewritten to incorporate source control: Developer A checks out awesome.java Developer A downloads awesome.java from the main file server. Developer A makes some changes to awesome.java to fix a problem. Developer B tries to check out awesome.java from the main file

server, but is refused. Developer A uploads the fixed awesome.java to the file server. Developer A checks in awesome.java Developer B checks out awesome.java Developer B downloads awesome.java from the main file server. Developer B makes some changes to awesome.java. Developer A checks out uses_awesome.java. Developer A downloads uses_awesome.java from the file server. Developer B uploads the fixed awesome.java Developer B checks in awesome.java Developer A fixes uses_awesome.java. Developer A uploads the fixed uses_awesome.java.

+Step Three: Integration

What’s the problem here? Developer A is making use of a version of awesome.java that may

not match his or her expectations.

Is this a problem with the social environment, or with source control? Answers on a postcard!

Answer – it may not be a problem at all. Or it might be.

Remember our talk about refactoring and impact of change. If the change takes into account the general courtesy of refactoring,

it shouldn’t matter to uses_awesome.java at all.

If a problem exists, it’s a problem with how changes are being made. Source control doesn’t fix this problem.

+Source Control Systems

There are many of these available.

The following graph comes from http://www.codinghorror.com/blog/archives/000660.html, and shows the popularity of packages.

+Summary

Collaboration is important in modern development. But it requires the social context to be addressed before the

tools can be put in place. Courteous development makes everyone’s life easier. Source control helps manage those situations where the

problems are technical rather than environmental.

Once you have the social context, you should consider rolling out the tools. If you need wikis and such, I can make them available if

you don’t want to set up your own.

Address the issue of collaboration early in your group work. It will save you much heartache later on down the line.