Posted by m.jackson on 8 May 2012 - 2:43pm

By Mike Jackson.

At the "what makes good code good and peer software reviewing" session we ran at Dev8D in February, there was discussion as to the potentially thorny issue of solo developers who may not want others looking at their code. Some people can be sensitive, defensive, or even aggressive at the suggestion that their code should be reviewed or changed, or even fixed!

From a technical perspective, sharing code is a solved problem. A reluctance to share code is a problem of psychology, team working and attitude. After all, programming is a social activity (contrary to the popular myth of the lone developers hunched in a dark room bathed in the light of a cathode-ray tube).

Encouraging developers to share code earlier rather than later, is a challenge not just within research but in software development in general (see, for example, these blog articles on "Don't go dark" and "Programmer insecurity"). In this article, various approaches to encouraging code sharing and communal ownership within a project are discussed.

"You'll do as you're told" (Coercive)

A simple approach, for project leaders or PIs, is to use their seniority to force their developers to share their code with their team mates and to just accept that it may be used, changed or fixed without their consent. The project leader is senior to the developer, so the developer must obey! This has a guaranteed result, maybe after much heel-digging, but incurs a major down-side of bad feelings all round and an upset or resentful developer.

"Actually, its not your code, it's your project's/university's" (Pedantic)

A variant of the above, this appeals to the simple facts of life. Developers are employees and their source code will likely be owned by their project, department or institution. So, it isn't in fact the developer's code, so it's not up to them how the code is used. However, such pedantic discrimination between perceived and actual ownership, may just end up degenerating into coercion above.

"What are your concerns?" (Inquisitive)

People who write code, whether they be novice researchers or experienced software developers, will naturally have some sense of ownership over what they create. And this, in turn, creates concerns when asked to share it with others. This may simply arise from ego: "I don't want someone messing up my code". Within research, people may fear that, by sharing their code, something innovative may be sacrificed and ideas may be stolen. This is indeed a risk, but if such doubt exists within a single project then arguably the project has greater issues to resolve than the reluctance of one of its members to share code. Most common, however, is that developers are reluctant to share code due to concerns that they will be judged on it, and criticised or mocked. This can lead to the delaying tactic of "It's not ready, yet, it's still messy". For example, Greg Landgraf reports on a survey of code sharing by librarians in which 51% cited perfection as a reason for not sharing their code.

Understanding why a developer might not share their code can help project leaders, PIs or peers to devise solutions to these concerns, perhaps using one or more of the approaches that follow.

"If you get hit by a bus...what do we do then?" (What-if)

This tries to appeal to the developer's sense of reason. It relates to what James Shore in The Art of Agile Development - Collective Code Ownership describes as the truck number metric, which is defined as How many people can get hit by a truck before the project suffers irreparable harm?

This approach asks the developer to consider the consequences if they are off sick, take leave or move on to another job. The rest of the team may be left with code they do not understand and cannot maintain. They may not have access to the most recent version of the code, or indeed have access to the code at all. This could cause major problems if the software has been released and a bug is found, or the latest version of the software is needed to do an analysis for a paper to be submitted to a conference with a tight deadline. Use of a shared, source-code repository and committing code regularly, rather than waiting till it's complete can overcome these risks, as can the suggestions that follow. As one blogger states, project leaders "should always plan for someone leaving/getting hit by a bus".

"We can grow and learn together" (Assertive)

This approach can also be expressed as you show me yours and I'll show you mine, because it emphasises the benefits of sharing.

By sharing code a developer does not open him/herself up to criticism or ridicule, but is instead made aware of new ideas and ways to do things. Other team members may suggest better solutions, mention useful coding tips, spot esoteric bugs, or suggest ways to make the code and its comments more readable. The developer, in turn, gets to practice these skills on their peers' code. The quality of the software as a whole can evolve as can the skills of all the members of the team.

"We work together on our code" (Community-minded)

Perhaps the most effective way to encourage code sharing is to shun the it's mine mindset from the outset of a project, and instead adopt a view of the code as its ours.

This can be termed collective ownership (which is one of the principles of agile development). Under collective ownership anyone can add functionality, fix bugs or refactor any code. This fosters an environment in which everyone is encouraged to contribute ideas across the project as a whole, knowledge about the code is shared, and no single developer is a bottle-neck. This helps reduce the impact of a developer leaving or becoming indisposed, which benefits both the team and its leader (as Tim Ottinger and Jeff Langr commented, "I would hate to be the manager who has to tell clients that he can't make the release date because he only has one programmer competent to do the work.").

Collective ownership can be encouraged by regular code reviews during which a developer reviews a peer's code for correctness and maintainability. These reviews also encourage developers to clean up and refactor their code as they go, rather than leaving it to the end (which never comes). Another approach to collective ownership (and agile method) is pair programming, where two developers write code side-by-side. Though this does take time to learn, and is highly dependant upon individual temperaments, it delivers collectively owned code from the outset.

To complement these approaches, a project can promote positive communication amongst the developers. No developer should just denoucce another's code as rubbish. Instead, they should identify potential pitfalls, explain why the pitfalls are problematic and propose alternatives. For example, "although that works, a more efficient alternative is this". This assertive (rather than aggressive) approach is far easier to accept when it is your code that is being critiqued! Tim Ottinger and Jeff Langer suggest that developers focus upon the nature and behaviour of the code, rather than the personality of its developers. Developers can also contribute to a constructive, collective atmosphere by respecting Jeff Atwood's Ten commandments of egoless programming.

Feedback

These are our observations on encouraging developers to share their code with their peers. Let us know what you think by email or by commenting below.